emkay Posted July 6, 2003 Share Posted July 6, 2003 @bryede I like that little controversy @Jetboot Jack I had some small tools written. One tool changed the Bitmap, that 712 was not longer the background. I mostly chose the darkest playfield color for Background. One tool converted directly the Picturedata into the Multifont. With the third tool it was possible to invert the chars and to set the PMg bits. If I only would find them.... 13years are a long time ... BTW: I think, because of the fact, that in Hires a Charmode will give no advantages, it would be a nice do to change the resolution in GED to Hires and create pictures like the "FORT". Link to comment Share on other sites More sharing options...
Bryan Posted July 6, 2003 Share Posted July 6, 2003 Ooh, that's what i've been trying to do for the last half an hour; can you explain how its done for a coder who only started on the Atari two days ago? =-) TMR, if no one else does it, I'll try to post something later. Here's what you need to know: $D000 - HPOSP0 (horiz pos Player 0) $D001 - HPOSP1 $D002 - HPOSP2 $D003 - HPOSP3 Maybe these too if you want the Missiles too $D004 - HPOSM0 $D005 - HPOSM1 $D006 - HPOSM2 $D007 - HPOSM3 Set the size of the players $D008-D00B - SIZEP0 - SIZEP3 $D00C SIZEM Set the graphic byte for the player (this works if player DMA is off. Works like the 2600 where you stuff the graphics manually - useful for making vertical stripes without needed to set up player RAM) $D00D - D010 GRAFP0-GRAFP3 $D011 GRAFM Player colors - these have shadow registers at 2C0-2C3 (values that are copied into the hardware registers on VBL by the OS). $D012-D015 COLPM0-COLPM3 $D019 COLPF3 - Playfield color 3, can be used as the color for the missiles (instead of the associated player color). Shadow 2C7 D01B PRIOR - Sets the priority of Playfield & Players (also sets GTIA 16 color modes). Set to 0 for mixed colors. Shadow 26F $D01D GRACTL Graphics Control. Bit 0 turns on Missiles. Bit 1 turns on Players. Gotta run.. hope this helped. Link to comment Share on other sites More sharing options...
TMR Posted July 6, 2003 Share Posted July 6, 2003 Thanks, it's helped in that it's proved what i've done so far is working (i have one player onscreen and the prioroties set to $00) but i'm using 160x192 graphics and it appears to have no effect at all. If i change to 320x192 the trick works though, is there something else i need to do...? Addendum: Okay, got a little further and two of three colours in my picture are changing. Why does the other one go black...? Link to comment Share on other sites More sharing options...
emkay Posted July 6, 2003 Share Posted July 6, 2003 TMR The main difference between Hires (f) and the colormode(e) is the background. In Hires it is (710) in colormode it is (712). So the Overlay in Hires is done by a player and a playfield color. To get the same effect in colormode, you have to draw something and you can see the effect. Link to comment Share on other sites More sharing options...
TMR Posted July 6, 2003 Share Posted July 6, 2003 i'm not sure how you mean, emkay; i'm getting two of my three colours changing appropriately but the third is just going black. Background colour is set to $00, playfield colours are $64, $66 and $68 and the player is set as $11 so the colours should OR out to $75, $77 and $79 respectively right...? Two of 'em are, one is going black. Link to comment Share on other sites More sharing options...
emkay Posted July 6, 2003 Share Posted July 6, 2003 Here is a table of prior and how the bits are working: PF -> Playfield P -> Player BAK ->Background Does the priority setting make no sense, the resulting color will be black. Link to comment Share on other sites More sharing options...
Bryan Posted July 6, 2003 Share Posted July 6, 2003 i'm not sure how you mean, emkay; i'm getting two of my three colours changing appropriately but the third is just going black. Background colour is set to $00, playfield colours are $64, $66 and $68 and the player is set as $11 so the colours should OR out to $75, $77 and $79 respectively right...? Two of 'em are, one is going black. Man, I'm gonna have to research this again myself. If GTIA thinks there's a priority conflict (like when 2 PRIOR bits are set at the same time) it turns the pixel black. Apparently, GTIA feels there's a conflict. Emkay posted the chart that shows this. If PRIOR = 3 then PF2 and Player 2 will conflict. -Bry Link to comment Share on other sites More sharing options...
TMR Posted July 6, 2003 Share Posted July 6, 2003 [Looks at chart,. blinks a couple of times and starts crying] i don't get it - i'm just used to sprite priorities being on or off?! i've been playing a bit more and a second player does the same thing, i set bit 5 in the priority register and the two PMGs combine colours but wherever they cross %11 in the bitmap data it's still black... i'm not barking up a tree that doesn't exist here, am i...? Link to comment Share on other sites More sharing options...
Bryan Posted July 7, 2003 Share Posted July 7, 2003 [Looks at chart,. blinks a couple of times and starts crying] i don't get it - i'm just used to sprite priorities being on or off?! i've been playing a bit more and a second player does the same thing, i set bit 5 in the priority register and the two PMGs combine colours but wherever they cross %11 in the bitmap data it's still black... i'm not barking up a tree that doesn't exist here, am i...? Okay, the meaning of the chart is this, my son (wise old man mode): In most cases, you are to pick 1 priority bit and set it. By the way, P=Player PF=Playfield. If you set bit 0 (PRIOR=1) The top object is P0. All other graphics appear to be behind P0. The next object is P1. Only P0 appears to be in front of P1. Next is P2. P1 & P0 are in front, everything else behind. Next is P3. P3 will appear to pass behind all other Players, but in front of the Playfield. Next are PF0-PF3. There cannot be more than 1 Playfield color per pixel, so the Playfiled is behind all the Players. Next is Background. The background color appears wherever there are no graphics. If you set bit 1 (PRIOR=2) Player 0 is in front. Player 1 is behind it. ...now things get interesting... Playfield appers here. Behind P0,1 but in front of P2,3. Players 2,3 will be obscured by playfield graphics, and will appear to pass behind them. Background, as always, has the lowest priority If you set bit 2 (PRIOR=4) The Playfield is in front. ALL Players pass behind. Players are only visible where there are no bits set in the PF. Where there are no players behind the playfield, you get background. If you set bit 3 (PRIOR=8 ) Playfield colors 0,1 are in front. All Players pass in front of these colors only Playfield colors 2,3 are behind the players. Background is in back of everything. If you set more than 1 bit... When a Player and Playfield priority are defined twice... PRIOR=6 (bit 1 & 2 set!) Now.... P0 conflicts with PF0 - When these overlap, there will be BLACK. P1 conflicts with PF1 - When these overlap, there will be BLACK. PF0 conflicts with PF2 - Cannot happen PF1 conflicts with PF3 - Cannot happen PF2 conflicts with P0 - When these overlap, there will be BLACK. PF3 conflicts with P1 - When these overlap, there will be BLACK. P2 has same priority either way. P3 has same priority either way. Backround always last. Note that all 4 missiles can be turned a different color to make a 'virtual' 5th Player (each missile is 2 pixels wide). This color is the same as PF3 and the missiles take on its priority. Does this make sense? -Bry Link to comment Share on other sites More sharing options...
TMR Posted July 7, 2003 Share Posted July 7, 2003 [Nods] Yes, that makes a lot more sense. =-) Okay, so my graphics going black because a PMG overlaps them is something i'll have to work around then. Ta very much. =-) (My next question is why doesnt RMT save driver code with the data... =-) Link to comment Share on other sites More sharing options...
Bryan Posted July 7, 2003 Share Posted July 7, 2003 TMR, here's more for you... ...This sets up a (very) low rez screen in 4 colors with a text window at the bottom 5 GRAPHICS 3 ...This makes all the Players & Missiles very wide (32 pixels each!) 10 POKE 53256,3:POKE 53257,3:POKE 53258,3:POKE 53259,3 ...Set the Player colors (using the shadow registers) 20 POKE 704,20:POKE 705,36:POKE 706,68:POKE 707,132:POKE 711,52 ...Set all the Players to 'all bits on' 30 POKE 53261,255:POKE 53262,255:POKE 53263,255:POKE 53264,255:POKE 53265,255 ...Set the Horizontal Positions (make Players overlap by 8 pixels) 40 POKE 53248,48:POKE 53249,72:POKE 53250,96:POKE 53251,120 ...Position the Missiles against each other (like a 5th Player) 50 POKE 53252,144:POKE 53253,152:POKE 53254,160:POKE 53255,168 ...Set some Playfield colors (Grayshades). 60 POKE 708,6:POKE 709,10:POKE 710,14 ...Set PRIOR (shadow register). No priority bits, 5th Player color option, Player color mixing enabled. 100 POKE 623,48 ...Draw some color bars in 3 shades of gray 120 COLOR 1 130 PLOT 0,0:DRAWTO 39,0 140 PLOT 0,1:DRAWTO 39,1 150 COLOR 2 160 PLOT 0,4:DRAWTO 39,4 170 PLOT 0,5:DRAWTO 39,5 180 COLOR 3 190 PLOT 0,8:DRAWTO 39,8 200 PLOT 0,9:DRAWTO 39,9 ...Program exits and displays READY in the textbox. The output is below. I threw this together, so I'm sure something better could be done with it. It appears that P0 & P1 both interact with PF0 & PF1. Also, it appears that P3 interacts with PF3. P0 & P1 are forming a 3rd color (the thin red stripe) and P3 & P4 are forming a 3rd color... and the Missiles (set to PF3) are forming a 3rd color with P3. What's even more interesting, is that the priority of the missiles seems to be affected by the colors behind them! Note the 2 red boxes sticking out of the missile area where PF0 & PF1 are. What I think we're seeing here are the effects of the underlying logic that make priorities work. -Bry Link to comment Share on other sites More sharing options...
Bryan Posted July 7, 2003 Share Posted July 7, 2003 By the way, check this out for some interesting player effects: A 256 byte intro. -Bry sintro.zip Link to comment Share on other sites More sharing options...
emkay Posted July 7, 2003 Share Posted July 7, 2003 Another (funny) Hires. Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 7, 2003 Share Posted July 7, 2003 Steve, just checked Shadow of the beast on C64... it's imho ugly... but question...did you planned to support paralax as well??? hve Link to comment Share on other sites More sharing options...
TMR Posted July 7, 2003 Share Posted July 7, 2003 Okay so i'm getting there slowly, got a reasonably nice static image with a picture in four colours and a 32 by 176 pixel logo in there using another three colours and one PMG (the last 16 pixels of the screen are a doublefont scroller). At the moment the graphics are mostly test to see if the concepts work, so if i've actually managed to attach the screenshot correctly it's not how it'll look in the final version... =-) At the moment the scroll runs fine and the test music (from Zero War) plays correctly, i've had no end of problems understanding RMT though; it's not like GoatTracker where the file is saved with a player ready to include into code and i don't even know which assembler the driver was written for...! Link to comment Share on other sites More sharing options...
TMR Posted July 7, 2003 Share Posted July 7, 2003 Heaven: Beast on the C64 is average at best, there have been better implementations done in demos although i can't think of a single one right now...! There's a really nice menu on the Amstrad CPC based on Beast too. Link to comment Share on other sites More sharing options...
Jetboot Jack Posted July 7, 2003 Author Share Posted July 7, 2003 Hve, Well we do have parallax in the demo -- 3 cloud speeds, the tree layer and the near foreground -- all at different speeds, but I guess you mean overlapping We were going to use PMG in certain areas for background objects above ground (trees, mountains) and use rotated character sets for parallax backgrounds underground... As to other 8bit versions of Beast -- they were all very poor -- except the XE version TMR -- hands off that Zero War musics -- I paid good money to get that tune made sTeVE Link to comment Share on other sites More sharing options...
TMR Posted July 8, 2003 Share Posted July 8, 2003 TMR -- hands off that Zero War musics -- I paid good money to get that tune made Don't worry it's not planned for the final version, one thing Cosine has in spades is musicians and we stopped using rips, regardless of how good the music is, around 1989 if memory serves (PC-89 on the C64 was our first rip-free product, the previous release Vladivar used background graphics from Armalyte). Sack has already been playing with Atari sound as well as trying out some code and 4-Mat (if anyone recognises the handle, yes that 4-Mat =-) seems to rise to just about any challenge i come up with so if someone explains how to use the bloody output from RMT without piddling around with an assembler too much (or at least which assembler to piddle with!) i'm sure one of 'em can be persuaded to make POKEY wail... =-) And who do i have to nag to get a relocating compiler built into RMT that saves a raw binary like GoatTracker does...? =-) Link to comment Share on other sites More sharing options...
Bryan Posted July 8, 2003 Share Posted July 8, 2003 And who do i have to nag to get a relocating compiler built into RMT that saves a raw binary like GoatTracker does...? =-) Bug Radek Sterba (Raster). Doesn't he have some playback code on his site? Did the BASIC code above help with your black pixel problem? -Bry Link to comment Share on other sites More sharing options...
Lord-Chaos Posted July 8, 2003 Share Posted July 8, 2003 Ooh, that's what i've been trying to do for the last half an hour; can you explain how its done for a coder who only started on the Atari two days ago? =-) Ok , my program uses character mode and only the 4 players. 5 GRAPHICS 12 10 For L=0 to 3 20 poke 53248+l,48+32*l 30 poke 53256+l,255 40 poke 53261+l,255 50 next l - creating and positioning the players in lowest resolution That means player 1,2,3 and 4 and the last 1/5 of screen is background 100 restore 1000 110 for l=0 to 3 115 read a:poke 704+l,a 120 next l -reading the player colors 130 move 224*256,128*256,1024 copying the charset from ROM to RAM.Note : This is a Turbo BASIC command , in BASIC you have to use a for - next or something like that 140 BASE=32768 150 for l=base+100*8 to l+7 160 poke l,0 165 poke l+8,170 170 poke l+16,85 175 poke l+24,255 180 next l 190 poke 756,128 - creating 4 new chars in the RAM and set the charset to this new location - 32768 is 256*128 210 for l=0 to 3 220 color 100+l 230 plot 0,l*2:drawto 39,l*2 235 plot 0,l*2+1:drawto 39,l*2+1 239 color 228+l 240 plot 0,l*2+8:drawto 39,l2+8 245 plot 0,l*2+9:drawto 39,l*2+9 250 next l draw a pattern on the screen. 260 poke 708,4 265 poke 709,8 270 poke 710,10 275 poke 712,0 280 poke 711,104 1000 data 48,128,176,80 setting the colors of the background.711 is the shadow register for the 5th color which you get when objects with use the 710 register are inverted. players 0 and 1 interact with background colors in 708,709 players 2 and 3 with the backround colors in 710 and 711. The advantage of character mode is the 5th color.In this picture it gives you 3 extra colors. I think this isn´t only useful for colorful pictures , but also for colorful software sprites. I don´t know yet if this works with the "display players twice per line" technique , if it does , the number of colors would be even higher. BTW : if you run the program in Graphics 0 on an NTSC system you´ll notice 2 extra colors created by artifacting.But artifacting isn´t really that useful , especially because the colors aren´t that great looking. Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 8, 2003 Share Posted July 8, 2003 several things before going to work: @ steve... to be honest the never released XE version of SOB could be among the best 8bit versions... if i look on the C64 one... @ TMR RMT uses XASM replay source code... most coders (from the scene) use XASM which our coder wrote for PC... xasm.atari.org RMT replay code is saved with the music or you rip it from Delta: check my thoughts on that: http://www.atariage.com/forums/viewtopic.p...0&highlight=rmt Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 8, 2003 Share Posted July 8, 2003 several things before going to work: @ steve... to be honest the never released XE version of SOB could be among the best 8bit versions... if i look on the C64 one... @ TMR RMT uses XASM replay source code... most coders (from the scene) use XASM which our coder wrote for PC... xasm.atari.org RMT replay code is saved with the music or you rip it from Delta: check my thoughts on that: http://www.atariage.com/forums/viewtopic.p...0&highlight=rmt Link to comment Share on other sites More sharing options...
Heaven/TQA Posted July 8, 2003 Share Posted July 8, 2003 TMR looks good! as you are coming from C64... don't forget to remove the borders with one STA where you initialise the PM gfx you have something like lda #62 sta $d400 ; or 559 don't know if you are using the hardware registers... now try #63 instead... and you should have fullscreen... of course it will mess up your hires gfx as your gfx is converted to 160x (40 bytes per scanline...) but at least your scroller should work in fullscreen... hve ps. great gfx! did your guys draw the pic + font? Link to comment Share on other sites More sharing options...
raster/c.p.u. Posted July 8, 2003 Share Posted July 8, 2003 (My next question is why doesnt RMT save driver code with the data... =-) You can export the RMT song as "XEX Atari executable msx export file (*.xex)". It contains player routine and song data together. Or you can export as "RMT stripped song file (*.rmt)" if you need the song data for some other memory location. (The RMT player routine isn't easy relocatible, therefore RMT ZIP package contains also Assembler source code of player routine (xasm.atari.org).) Link to comment Share on other sites More sharing options...
Bryan Posted July 8, 2003 Share Posted July 8, 2003 You can export the RMT song as "XEX Atari executable msx export file (*.xex)". It contains player routine and song data together. Or you can export as "RMT stripped song file (*.rmt)" if you need the song data for some other memory location. (The RMT player routine isn't easy relocatible, therefore RMT ZIP package contains also Assembler source code of player routine (xasm.atari.org).) Hey Raster! Nice to see you here! -Bry Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Archived
This topic is now archived and is closed to further replies.