Jetboot Jack Posted August 6, 2003 Share Posted August 6, 2003 LC, I get it, I really do, but a double buffered display in Antic 4 with 8 charsets per buffer is still more RAM costly than doing it in Antic E, and you have lots more housekeeping overhead to finagle the whole display with the charmapped mode... So I don't see the real value of going to all the trouble for one extra color in the PF. For example certain games: If I wanted to do, say Bubble Bobble, then I would probably choose Antic E, with some DLI for extra colors and PMG (maybe overlaid) as the easiest route to a working game, with less RAM overhead too. If it was to do say Xevious then I may use hardware scrolled Antic 4 with PMG for flying enemies, like last guardian -- but with 2 independent enemies per line (ok they would flicker if they got on the same line as the player's ship, but heck so what, better than the 5200 travesty)... If it were a display for say R-type I might go for 80 lines of Antic D (20k)and lots of software sprites (or do it like the Menace demo in Antic 4) Ghosts and Goblins on the other hand -- a plan still eludes me sTeVE Quote Link to comment Share on other sites More sharing options...
Bryan Posted August 6, 2003 Share Posted August 6, 2003 Bubble Bobble - Theres a game that would be a good conversion for the 8bit..... I agree. That would be cool. -Bry Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted August 6, 2003 Share Posted August 6, 2003 Jb, thats exatcly my initial theory... use the optimal technique vs the best technique depending on time, resources, goals, etc... otherwise all studios would license the unreal2 engine and build mario 2d or tetris game out of it... what a waste of resources..... this thread reminds me as well when we discussed my time pilot conversion project... can you remember steve? you suggested & made mockups of gfx with pmg overlays... the engine still is running ("zone ranger") but the engine is built around antic e... and very simple to write compared to the ones discussed here... but i'll try these charmode thingy out... seems like similar technique then we have discussed on atari 7800 as well... (moving vertical sprites & gfx zones...) hve Quote Link to comment Share on other sites More sharing options...
TMR Posted August 6, 2003 Share Posted August 6, 2003 Please note that with the memory of a 130XE you can pre-calculate a lot and store it in the extra - RAM , so that you can gain speed.This can be done on a 64K machine,too , if you have a small main program and divide a game into levels that can be loaded from disk. The other option is to have some cache space put aside and precalc movements for each level or screen to it, if you limit yourself to one or two object definitions and they don't need to overlap background detail it's possible to do things pretty fast. And data on disk can be compressed , many C64 games like load huge level data and decompress it , although a few very impressive games like Wizball are in 64K. One of the more impressive feats i've seen was a cracked version of Fred's Back that took all the level files and crunched them into memory with the main game, essentially onefiling it. Fred's Back uses an AGSP scroller to shift a bitmap around so it's quite tight on memory. Simple tile or column/row compression makes it possible to shove large wodges of background data into one load. And although PAL ATARIs can display up to 240 lines , it´s not recommended to use more than 200 , otherwise such games coul become unplayable on an NTSC machine. How do i balance that out in the display list, do i need $70,$70,$70 at the top or can i use $70,$70,$30 to centre a 200 line display...? And there are computers with no sprites/scrolling at all - Amstrad CPC for examples - that have fast action games.The Amstrad for example is a ca. 4Mhz Z80 machine , but uses a 16K 160*200 16 color screen AFAIK (or 4 colors in 320*200) and this means twice as much as the XL (so it loses the advantage of the twice-as-fat CPU) .But Turrican , Silkworm and other fast action games are available ! Most of the CPC action games i've seen are quite slow, i think CPC Turrican is dropping three to four frames per refresh and i'd consider that unacceptable. Hardware-based vertical and fast (8 pixels a frame) horizontal scrolling are both possible on the CPC by messing with the CTRC, by allowing for the repositioning of the screen in the software sprite routine and writing over the data that's just wrapped around it's theoretically possible to hammer a full screen full framerate scroll with the majority of the CPU power available for the sprites. Oh, for reference the Z80 used in the Amstrad requires close to twice as many cycles a command as the 6510 in the C64, meaning it's only about twice the speed in real terms and the Atari's 6502 should therefore be damned close to matching it. Quote Link to comment Share on other sites More sharing options...
Sheddy Posted August 6, 2003 Share Posted August 6, 2003 And although PAL ATARIs can display up to 240 lines , it´s not recommended to use more than 200 , otherwise such games coul become unplayable on an NTSC machine. How do i balance that out in the display list, do i need $70,$70,$70 at the top or can i use $70,$70,$30 to centre a 200 line display...? And there are computers with no sprites/scrolling at all - Amstrad CPC for examples - that have fast action games.The Amstrad for example is a ca. 4Mhz Z80 machine , but uses a 16K 160*200 16 color screen AFAIK (or 4 colors in 320*200) and this means twice as much as the XL (so it loses the advantage of the twice-as-fat CPU) .But Turrican , Silkworm and other fast action games are available ! Most of the CPC action games i've seen are quite slow, i think CPC Turrican is dropping three to four frames per refresh and i'd consider that unacceptable. Hardware-based vertical and fast (8 pixels a frame) horizontal scrolling are both possible on the CPC by messing with the CTRC, by allowing for the repositioning of the screen in the software sprite routine and writing over the data that's just wrapped around it's theoretically possible to hammer a full screen full framerate scroll with the majority of the CPU power available for the sprites. Oh, for reference the Z80 used in the Amstrad requires close to twice as many cycles a command as the 6510 in the C64, meaning it's only about twice the speed in real terms and the Atari's 6502 should therefore be damned close to matching it. It's OK to leave the normal blank line stuff in the top of display list, as the PAL or NTSC hardware compensates so both will appear centred using the same display list. The 16K bitmap amstrad screen is just a little too big for an 8-bit to really handle comfortably, although I would have loved for such a mode available on the atari or the c64 (think of the DMA cycle stealing/bad lines though!) Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted August 6, 2003 Share Posted August 6, 2003 As an offshoot, the BBC had a higher res 4 colour mode, 320 * 200 I think. Hence a previously planned port of the fantastic 'Tetrapod' I wanted to do won't happen A teletext type mode on the XL would have been nice though. Quote Link to comment Share on other sites More sharing options...
emkay Posted August 6, 2003 Share Posted August 6, 2003 Please note that with the memory of a 130XE you can pre-calculate a lot and store it in the extra - RAM , so that you can gain speed.This can be done on a 64K machine,too , if you have a small main program and divide a game into levels that can be loaded from disk. The other option is to have some cache space put aside and precalc movements for each level or screen to it, if you limit yourself to one or two object definitions and they don't need to overlap background detail it's possible to do things pretty fast. As I wrote before... The fastest way to create action games is to simple copy screendata. Why not using PMg for the main backround and charmode-clusters for softwaresprites and movement... OK. The gamer will sometimes see a character-form on the screen but ... so what? In Turrican (2) on the C64 the charmode-blocks are hitting your eyes, and everyone is whining after all...: XL has no Turrican... The second thing is the XLs speed... compared up to the CPC the XL has relative the most CPU-time available. I wonder if anyone is taking care about that. The third thing is the memory. All above simple 7680 Byte screen is to fear because there is "too much RAM usage". I am still wondering where the megs. of the C64 are Quote Link to comment Share on other sites More sharing options...
TMR Posted August 6, 2003 Share Posted August 6, 2003 The second thing is the XLs speed... compared up to the CPC the XL has relative the most CPU-time available. I wonder if anyone is taking care about that. They're about the same, the speed advantage of the XL comes from the smaller memory overhead for screen data and therefore lower numbers of transfers to move stuff around. The third thing is the memory. All above simple 7680 Byte screen is to fear because there is "too much RAM usage".I am still wondering where the megs. of the C64 are The C64 is normally relying on a character based screen and hardware sprites, with only 128 characters in a set it's harder to do software sprites that way (pre-rolled or otherwise). Reaxion Plus/4 runs on a char-based screen, but it's quite sneaky about it's colours... Quote Link to comment Share on other sites More sharing options...
Sheddy Posted August 6, 2003 Share Posted August 6, 2003 How do i balance that out in the display list, do i need $70,$70,$70 at the top or can i use $70,$70,$30 to centre a 200 line display...? so, this time actually answering your question ......$70,$70,$30 would do it BTW My brother started having a go at converting Bubble Bobble for the atari, before he moved over to the "dark side" - Amiga (his demo handle was "The Bunge"). Unfortunately, after touching the Amiga, he never went back to finish it. He had a cool map editor, that automatically did the drop shadows on the level layouts - but then he was always a clever sod! Actually I love the Amiga (thank you Mr Miner et al) 'coz it's so similar to the atari in many ways. Just hate the skinny sprites (same problem as atari) Quote Link to comment Share on other sites More sharing options...
emkay Posted August 6, 2003 Share Posted August 6, 2003 TMR >They're about the same, the speed advantage of the XL comes from the smaller memory overhead for screen data and therefore lower numbers of transfers to move stuff around. The graphics-memory is at half Less cycles are used for commands Hardwarescolling will buffer/save frames Charmode is allways faster to handle >The C64 is normally relying on a character based screen and hardware sprites, What does that mean? 2048Bytes for one charset? 1000Bytes for Screendata? 1000Bytes for color-cells? How much memory are the sprites using? Is one Charset enough for the whole screen? Is the machine able to put a game without exeptional programming? -How much CPU speed does this cost? In addition: How much time does it cost to full program all SID registers? etc. etc. etc. Quote Link to comment Share on other sites More sharing options...
TMR Posted August 6, 2003 Share Posted August 6, 2003 2048Bytes for one charset?1000Bytes for Screendata? 1000Bytes for color-cells? The colour cell data is stored in dedicated memory and shadowed over some of the RAM at $d800 - that space can be used twice effectively so no real overhead. Similarly, it's possible to push graphics data under the VIC-II and SID registers and the Kernel and BASIC ROMs too so that frees quite a bit of space. How much memory are the sprites using? 63 bytes each, in 64 byte steps. Is one Charset enough for the whole screen? Depends, it can be for a lot of things but i tend to use a second one for any status bars. My vertical scrolling shoot-em-up Cyberwing uses two background charsets and a third for text. Is the machine able to put a game without exeptional programming? Yes, full screen scroll with eight sprites is fairly simple stuff - my first real game looked like that. It's more fiddly to get the split screen going on the C64 than the Atari, but after that learning curve the rest is easy. -How much CPU speed does this cost? Depends, full screen double buffered scroll taks about a quarter to a fifth of the raster time, the rest of the work is processing sprite positions and collision events. Add a colour scroll, it gets a lot tighter... In addition: How much time does it cost to full program all SID registers? At a guess, about 12-14 rasterlines for a fast music driver to around 24 or 32 for an average - effects take less. Quote Link to comment Share on other sites More sharing options...
emkay Posted August 6, 2003 Share Posted August 6, 2003 TMR >The colour cell data is stored in dedicated memory and shadowed over some of the RAM at $d800 - that space can be used twice effectively so no real overhead. That was not the point, why I asked for it. Only to manage the Data needs memory already. >63 bytes each, in 64 byte steps. So 512k at least for Sprites. >Yes, full screen scroll with eight sprites is fairly simple stuff And it costs memory to handle them and DMA reads cost CPU Time... By all the Hardwarefeatures, they have to be handled too. If a game don't take advantage by the hardwarefeatures, everything has to be programmed by software. This is like the possibility of building graphics with 128 colors by "raster" programming. Without "raster" programming, the C64 has more colors on the screen than the XL. Or using interlace.... without, the C64 is able to show 16 colors at 320x200. With interlace 128 colors are possible. Without Interlace the XL can only show two brightnesses and with interlace 16000 colors at 320x240 would be possible. Similar by adressing POKEY faster at timings.... Do you follow my thoughts? Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted August 6, 2003 Share Posted August 6, 2003 nope... hve ps. when will this thread end... and we go back to the keyboards and through some LDAs together... Quote Link to comment Share on other sites More sharing options...
emkay Posted August 6, 2003 Share Posted August 6, 2003 nope... hve ps. when will this thread end... and we go back to the keyboards and through some LDAs together... Perhaps coders are making themselves clear, how to use the strength of the 8-bits to code the maximum out of that machines, without retirering at the first step they are doing? Quote Link to comment Share on other sites More sharing options...
TMR Posted August 6, 2003 Share Posted August 6, 2003 >The colour cell data is stored in dedicated memory and shadowed over some of the RAM at $d800 - that space can be used twice effectively so no real overhead. That was not the point, why I asked for it. Only to manage the Data needs memory already. Not really, for something simple i just write $08 across the entire map and generate colours with the background and multicolour registers - almost like programming the Atari really. So 512k at least for Sprites. Erm, 512K for sprites...? Are we talking about something specific here 'cos i was generalising? 16 sprites take 1K. And it costs memory to handle them and DMA reads cost CPU Time... That's a given for any machine with a DMA/badline system, surely? Do you follow my thoughts? To be honest, no. i'm slightly confused how we got from a comparison between the CPC and Atari to the C64 like this...? Quote Link to comment Share on other sites More sharing options...
TMR Posted August 6, 2003 Share Posted August 6, 2003 when will this thread end... and we go back to the keyboards and through some LDAs together... What, did everyone else stop or something? [Looks at first test source for Reaxion A8...] Quote Link to comment Share on other sites More sharing options...
analmux Posted August 7, 2003 Share Posted August 7, 2003 Ok let's calculate the amount of available CPU cycles on the Atari. 1789790 cycles/second: 35795 cycles/frame (50 fps Europe!! 60 fps is worse) -8640 cycles/frame DMA Antic mode 4 (40 * 24 * (8+1) reads) screen and fontdata -1280 cycles/frame DMA Players & Missiles (Hi-res) 25875 cycles/frame remaining for the CPU, which could be used for about 2700 LDA a,x - STA a,x instructions. Roughly speaking, you can easily change the data of 256 characters, including software sprites Note that the C64 must move its whole screen for a simple scroller: 2000 bytes (screen + color RAM). Although this is not always necessary every frame (especially with slow fine scrolling), this is used in games like Turrican II: Just watch the amazing fastscroll in level 3-3, with multilevel scrolling tiles for pseudo-3D. The first time I saw this my mouth fell open. But now I remember, there wasn't too much color in that level, so it could even hold color-Ram static on the whole screen or at least in certain areas of the screen. About memory-usage: Think about how Turrican II handles this problem: levels of 16 KB on a floppy. It uses 8 KB for the leveldata only (1 byte for each 4*4 charactercluster) and additional data for enemy positioning, enemy-movement tables and the fonts and numerous sprites, which are all different in each world. (Yes, I've never seen a better game on the 8bits) About color-usage: Graphics with PM overlay and Prior=0 should be treated very carefully. Only PM0/1 overlays with PF0/1 and PM2/3 with PF2/3 BUT the main problem is that PM0/1 also CLIPS PF2/3 which results in a decrease of colors in that region. But with some clever design I think you could make graphics like SONIC 2 on Atari. Most of the graphics (though not the same high resolution) of Super Mario 2 & 3 is possible on atari, in combination with PM-overlay and Prior=4 (PM shines through at BG). I'm working on images of SONIC 2 and SMB2/3. Prior Number of overlay colors 0 11 4 9 32 21 36 15 Off course you could write a whole game in TIP textmode graphics 0 (other modes decrease GTIA 11 colordepth). With even digital sound sampled by the DLI's needed for TIP. But I think that configuration is more useful for demos. But there is hope: We could construct the screen like this, in most platformgames: -24 lines Antic 4 -Every two lines a DLI that changes the characterset, the 9 colorregisters, PM positions and refreshes Pokey's soundregisters for creating pseudo-complex effects and music. -12 fonts that are the same for tiles and blocks that are used very often (such as the ?-blocks from Mario games), and don't change frequently, but the remaining characters of each font can be used for software sprites (multiple shift-phases) and characters from a different layer that scrolls at a different speed. Also precalculated characters. You could use a shift table that contains the 2 and more times ASL/ROL/LSR/ROR-ed bytes for fast software sprites. -A VBI to smooth scroll and trigger the screendata-changes, and also to move the (course resolution) PM data for vertical scrolling. Note: You don't have to move PM data EVERY frame when using Prior 4 overlay (shine-through) In this way you can divide a level in zones with different graphics and colors, by letting a smart background program update the fonts (i..e.) every 50th frame, or every time you move precisely one screen to the left or right, when the screendata needs a little treatment. And you can reserve lots of characters for exceptional events when for example a software sprite overlaps a bit of background, all precalculated in the so-called refresh-frame (every 50th frame). This might be a technical difficulty but with clever design it should be possible. I am working on the principles of this so called 'smartfont' screenmanaging, and I am planning to use this idea in a game, similar to Super Mario 2 & 3 and Sonic 2, that I am planning to write, for which I will write a demo with some of the game situations first. --------------- analmux Quote Link to comment Share on other sites More sharing options...
TMR Posted August 7, 2003 Share Posted August 7, 2003 Note that the C64 must move its whole screen for a simple scroller: 2000 bytes (screen + color RAM). Although this is not always necessary every frame (especially with slow fine scrolling) The screen can be double buffered but the colour map can't (it's fixed at $d800, an oversight that doesn't apply to the VIC20 and Plus/4) so it has to be moved in one fast shift. VSP and AGSP scrollers allow for "wrap around" scrolling so they're a lot faster and have a much lower overhead; Mayhem In Monsterland uses a VSP scroller so it's only writing about 50 bytes of data a frame even when moving at full speed, although there are pulses of data updates when the VSP is reset once every 40 characters but a sneaky use of buffers soaks that up. Scrolling a bitmap horizontally at a character (4 multicolour pixels) a frame with colour maps using VSP has been done, now i think about it i shall have to experiment again with that idea... =-) Quote Link to comment Share on other sites More sharing options...
analmux Posted August 7, 2003 Share Posted August 7, 2003 VSP and AGSP scrollers allow for "wrap around" scrolling That sounds very new to me. How is it done? As far as I know the C64 can't change the starting adress of the screenmap under 1 kB-precision. And what does 'double buffering' mean? Quote Link to comment Share on other sites More sharing options...
TMR Posted August 7, 2003 Share Posted August 7, 2003 VSP and AGSP scrollers allow for "wrap around" scrolling That sounds very new to me. How is it done? As far as I know the C64 can't change the starting adress of the screenmap under 1 kB-precision. VSP allows a horizontal offset of the start of the screen by up to 39 cycles, effectively pushing the start screen to the right in eight hi-res pixel steps. AGSP can do a combination of linecrunch and VSP, in other words it can pretty much specify where in a block of 8K the screen starts; AGSP isn't very popular for game use because it's tricky to work with (and you have to allow for the sprite data pointers at the back end of the screen moving around visibly when they wouldn't normally!) but games like Creatures and Mayhem In Monsterland both use it along with a bitmap scrolled beat-em-up i forget the name of right now... =-) And what does 'double buffering' mean? A fairly standard technique, two screens where one is displayed as the next is drawn, when the next frame is ready/needed the buffers swap jobs. Quote Link to comment Share on other sites More sharing options...
emkay Posted August 7, 2003 Share Posted August 7, 2003 So 512k at least for Sprites. Erm, 512K for sprites...? Are we talking about something specific here 'cos i was generalising? 16 sprites take 1K. Ofcourse 512 Bytes or 0,5K ... sorry Quote Link to comment Share on other sites More sharing options...
emkay Posted August 7, 2003 Share Posted August 7, 2003 Analmux >1280 cycles/frame DMA Players & Missiles (Hi-res) In MCS the PMg has fixed positions and the playfiled has the "hi" priority. By this you can use the lower res. of the PM to save cpu time and memory. By leaving the PMg static and only setting the bits to fit the sprites-movement: In theory it was the better way to create a PMg overlay at the background movement and to use the playfield colors only for the sprites. The charmode is recommended too, when using overlay ticks. So please remember, the color-registers "708 and 709" are treaded the same way and "710 and 711" are treated the same way. By your calculation ot the CPU-usage, it must be possible to copy ranges of the screen without flickering and double-buffering would be unnecessary. Quote Link to comment Share on other sites More sharing options...
TMR Posted August 7, 2003 Share Posted August 7, 2003 Okay, having problems with PMG priority again... is it possible to have two players mixing colours and two more that are just over the top of everything? i'd like to get the first two mixing but not the others... Quote Link to comment Share on other sites More sharing options...
emkay Posted August 7, 2003 Share Posted August 7, 2003 TMR >That's a given for any machine with a DMA/badline system, surely? This belongs to all computers up to a modern Hyperthreading P4 PC. When APG is fetching data from the Memory, the CPU has to wait. >To be honest, no. i'm slightly confused how we got from a comparison between the CPC and Atari to the C64 like this...? Now.. even on the CPC very much colorfull games are done, like on C64. And now find the way: The C64 has more advantages on the graphics-chip but a much slower CPU. The CPC has a faster CPU but much disadvantages to create games though. So why should it be impossible to create very good and colorfull games on the XL? The most times in the past I "saw" coders that learned on the XL/XE and to get better programs, they bought a better computer... Quote Link to comment Share on other sites More sharing options...
emkay Posted August 7, 2003 Share Posted August 7, 2003 Okay, having problems with PMG priority again... is it possible to have two players mixing colours and two more that are just over the top of everything? i'd like to get the first two mixing but not the others... Did you check this thread? http://www.atariage.com/forums/viewtopic.p...=31520&start=25 By using the prior colormixing, you only have two colors to "filter" the PM resolution. But I am more interested in how you will get the 4 bytes left to overlay ... Quote 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
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.