Creature XL Posted February 2, 2015 Share Posted February 2, 2015 The question is, "Why?". I'm not saying sprites are useless. if you want a reasonable number of animated objects sprites are convenient. Not sure if I got this link from AA or another forum. But Amiga sprites seem to have value: http://www.codetapper.com/amiga/sprite-tricks/ Quote Link to comment Share on other sites More sharing options...
kenjennings Posted February 2, 2015 Share Posted February 2, 2015 Not sure if I got this link from AA or another forum. But Amiga sprites seem to have value: http://www.codetapper.com/amiga/sprite-tricks/ That's really cool stuff. I assumed Copper should be able to reuse sprites horizontally. Had not seen anyone document that it is effective enough to use sprites as another playfield layer. So, then, "Why not?" :-) Quote Link to comment Share on other sites More sharing options...
+MrFish Posted February 2, 2015 Share Posted February 2, 2015 To my theoretical knowledge, the NES gfx hardware handles teh flicker not the programmer. You can move 64 sprites around at will, however, if more then 8 are on a scanline the PPU decided which one to draw. As NES sprites are 8x8 pixels I guess you think about "tile flickering". As stated, no experience with actual coding NES. So if I wrote nonsense, correct me gently please. From what I've read, the hardware will handle it for you, but in a destructive way. If you have 9 tiles on a line, then it will just not draw the ninth one. There is no rotation of drawing, it just dumps the last one. So if you want to be sure your tile at least gets drawn at some point, you need to take care of it yourself. If you're a lazy programmer, you can just let the chips fall where they may and some things may disappear for a while. I guess the terminology with the NES can get mixed up when it comes to tiles and sprites. I'm calling a sprite here a single animated entity/character in a game, which may be made up of one or more 8x8 tiles. So if a single tile is flickering for a sprite built out of 4 tiles, it's gonna look a little odd, as you start to see the straight tile edges and only part of the sprite flickering. And really it's not too dissimilar to what I'd expect to see on the Atari. If I had a sprite or character (whatever you want to call it) made out of two players, I wouldn't want to flicker one player, which might make up the flesh color, and not flick the other, which might be the body/clothes, or visa versa. It'd look a little odd. I suppose on the other side of the coin, some people might think to make as little overall flicker as possible, and thus only flicker what was absolutely necessary, which may have been the thinking behind the flickering in Crownland. Nothing wrong with it from a logical standpoint, it just doesn't look that good to most people. 2 Quote Link to comment Share on other sites More sharing options...
emkay Posted February 2, 2015 Share Posted February 2, 2015 (edited) But, Amiga sprites use the same color registers as the playfield so they do not contribute extra color as does Atari Player/Missiles. Really? I was a bit disappointed when reading about the "Rescue on Fractalus not fast enough on the Amiga"... You could set the Amiga's playfield to 2 Bitplanes and use the blitter as a screen filler for pixels bigger than "320x200". And, you could add the Sprites with their own colours... multiplexed, to enhance the colours on the screen . It would have looked like a PC game then... Edited February 2, 2015 by emkay Quote Link to comment Share on other sites More sharing options...
popmilo Posted February 2, 2015 Share Posted February 2, 2015 Hey Pop where is that C64 game map you send me some years ago? I remember it was only the level1, is there anywhere the other levels? Found it... Can't believe we were talking about it in 2011 Back to multiplexed sprites. Here is a good example of speed, color and numerous objects "Delta space arena": Quote Link to comment Share on other sites More sharing options...
Chilly Willy Posted February 3, 2015 Share Posted February 3, 2015 But, Amiga sprites use the same color registers as the playfield so they do not contribute extra color as does Atari Player/Missiles. Really? There are 32 color registers (in OCS/ECS). The first 16 are exclusive to the playfield, and cover one layer of 16 colors, or two layers of 8 colors each. The last 16 color registers are used by the sprites, or by a single layer playfield of five or six bitplanes. So only the second 16 colors are POSSIBLY shared. When sprites are in four color mode, pairs of sprites share four colors, the first actually being transparent. So color regs 16, 20, 24, and 28 are not shared in four color mode, but exclusive to the playfield. If you put a sprite pair into attached mode, they show 16 colors - all the upper color registers... except the first which is again transparent. So color 16 is always exclusive to the playfield regardless of the sprite mode. 20, 24, and 28 may or may not be exclusive. The idea was that most games would use two playfields of 8 colors each, leaving all the upper color registers for the sprites. Single playfields of 32 or 64 colors have to share most of the upper color registers. 1 Quote Link to comment Share on other sites More sharing options...
emkay Posted February 3, 2015 Share Posted February 3, 2015 The idea was that most games would use two playfields of 8 colors each, leaving all the upper color registers for the sprites. Single playfields of 32 or 64 colors have to share most of the upper color registers. The idea is the same as on the A8. Just with more powerful Hardware. Btw. It also allowed to have more colours on the screen when it's set to parallax mode. The screen allows up to two times 8 colours, while the "Hardwareprites" use their own colours. As the Amiga has the 5 Bitplane mode to reach all 32 colour registers, this equals somehow with "Gr.10" 1 Quote Link to comment Share on other sites More sharing options...
Chilly Willy Posted February 4, 2015 Share Posted February 4, 2015 The idea is the same as on the A8. Just with more powerful Hardware. Btw. It also allowed to have more colours on the screen when it's set to parallax mode. The screen allows up to two times 8 colours, while the "Hardwareprites" use their own colours. As the Amiga has the 5 Bitplane mode to reach all 32 colour registers, this equals somehow with "Gr.10" The more you examine the Amiga chipset, the more obvious it becomes the lineage it shares with the Atari. Even the way they updated Denise for Extra-Half-Brite mode brings to mind the update from CTIA to GTIA. It's too bad they didn't have something like the A500 to start with; they probably would have done better given how well the 500 did three years late to the party. 1 Quote Link to comment Share on other sites More sharing options...
popmilo Posted February 5, 2015 Share Posted February 5, 2015 I suppose on the other side of the coin, some people might think to make as little overall flicker as possible, and thus only flicker what was absolutely necessary, which may have been the thinking behind the flickering in Crownland. Nothing wrong with it from a logical standpoint, it just doesn't look that good to most people. Stumbled onto interesting point about sprite flicker in new Pacman version for 2600: Ed Temple's comment about a 'trick' he used in Amidar: http://atariage.com/forums/topic/229152-new-pacman-for-atari-2600/?p=3158174 What he did is simple - Sprites closer to player have "higher priority". They get more 'frames displayed' then far away sprites... Basically what he said was "Who cares if some sprite flickers or is not seen on other side of screen where it can not kill you anyway..." Will try to implement it and see how it compares.... 6 Quote Link to comment Share on other sites More sharing options...
analmux Posted February 5, 2015 Share Posted February 5, 2015 hat he did is simple - Sprites closer to player have "higher priority". They get more 'frames displayed' then far away sprites... Basically what he said was "Who cares if some sprite flickers or is not seen on other side of screen where it can not kill you anyway..." Will try to implement it and see how it compares.... Maybe another trick: if some enemies on screen has a large distance, then maybe it's enough to use PF characters instead. Only turn these coarse blockery PF chars into a real PM when it's close to the player. 2 Quote Link to comment Share on other sites More sharing options...
+MrFish Posted February 5, 2015 Share Posted February 5, 2015 Here's another idea: when using multicolored players, for enemies that are far away, allow them to be single color until close. 2 Quote Link to comment Share on other sites More sharing options...
Creature XL Posted February 5, 2015 Share Posted February 5, 2015 What he did is simple - Sprites closer to player have "higher priority". They get more 'frames displayed' then far away sprites... Basically what he said was "Who cares if some sprite flickers or is not seen on other side of screen where it can not kill you anyway..." Will try to implement it and see how it compares.... Actually a neat idea. Guess depends on the game how it looks. Will defo keep it in mind The idea with the conversion of PMG to char (if I understood that correctly) is maybe to hard. Again, depending on game or engine. Using single color instead of multi-color in tight situation might look awkward. Needs to be tested. What shouldn't be missed is that nowadays most games get "judged" by Youtube videos. So the fact that the "ugly" sprite is far away from the player sprite isn't useful. As always with my negative views on things - I am happy to be proofed wrong Quote Link to comment Share on other sites More sharing options...
emkay Posted February 5, 2015 Share Posted February 5, 2015 Actually a neat idea. Guess depends on the game how it looks. Will defo keep it in mind The idea with the conversion of PMG to char (if I understood that correctly) is maybe to hard. Again, depending on game or engine. Triggering the moving elements, use some special code , would make less problems than a "universal" Sprite routine. Using single color instead of multi-color in tight situation might look awkward. Needs to be tested. This points to a great game idea for the A8. Enemies from the shadow.... Till today, there is only Archon that uses the colour palette for a game rule indicator. What shouldn't be missed is that nowadays most games get "judged" by Youtube videos. So the fact that the "ugly" sprite is far away from the player sprite isn't useful. Or, how's about an evolution game .... if the enemies were far from the "Hero" they were just some eggs. When the player gets close, they turn into any bird Heck, on the C64 exists a demo that is build upon the limited palette, excusing the disordered colours by the environmental light... As always with my negative views on things - I am happy to be proofed wrong You know the problem with an iceberg? It's a 7th of the mass that is visual. If you turn it top down, you may see the other 6/7 but it will soon sink to the 1/7 again. Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted February 5, 2015 Share Posted February 5, 2015 Here's an idea: A platform game which uses hills and slopes instead of flat surfaces. Most enemies there will be on their own scanline, therefore will not flicker. Quote Link to comment Share on other sites More sharing options...
emkay Posted February 5, 2015 Share Posted February 5, 2015 Or create a game in gr. 7 and reused PMg ... http://youtu.be/xQVi0k5nUTI?t=21m17s Look at the arrangement of that level. Many enemies move symmetric /mirrored on one scanline. On the Atari this wouldn't flicker , you simply could reuse the PMg . Also. The "diagonal" style needs to have the square pixelation, to have it hor. & ver. looking the same... Use gr. 13 for that... Quote Link to comment Share on other sites More sharing options...
Creature XL Posted February 5, 2015 Share Posted February 5, 2015 Or create a game in gr. 7 and reused PMg ... http://youtu.be/xQVi0k5nUTI?t=21m17s Look at the arrangement of that level. Many enemies move symmetric /mirrored on one scanline. On the Atari this wouldn't flicker , you simply could reuse the PMg . Also. The "diagonal" style needs to have the square pixelation, to have it hor. & ver. looking the same... Use gr. 13 for that... This example is not counting as it is vertical. That a vertical shooter can be made on the A8 is well known an even an example posted in this thread (maybe even by yourself ). Further, as we have no real raster-line interrupt we would have a hard time to use this kind of multiplexing in char-mode. Feels like I said it earlier. Looking at the Turican vid, it seems accepted that there need not to be background music. If that is so, then POKEY-timer for raster IRQ is of course an option. Quote Link to comment Share on other sites More sharing options...
emkay Posted February 5, 2015 Share Posted February 5, 2015 (edited) This example is not counting as it is vertical. That a vertical shooter can be made on the A8 is well known an even an example posted in this thread (maybe even by yourself ). Further, as we have no real raster-line interrupt we would have a hard time to use this kind of multiplexing in char-mode. Feels like I said it earlier. Looking at the Turican vid, it seems accepted that there need not to be background music. If that is so, then POKEY-timer for raster IRQ is of course an option. .... maaaaannnnn..... Turrican on the C64 is also build on different programming "tricks" and sub routines. The vertical scrolling doesn't stop, so the Displaylist management has the full control on how a DLI can get started, which means : What you see on the Screen is always fully placed right into the scene. POKEY timers weren't much helpfull there. The important parts were: One Charset is enough to fill the whole screen, when using "gr. 13" . Screen handling gets also rather low, AND you get some more cycles compared to gr. 12 ... You could trigger any DLI by pointing to the DLI Adresss and start the DLI where it has to start. No Problem there, if a DLI uses 1/3 of the screen, because 800-960 Bytes fill the screen, and the parallax is done by an additional change of the charset.... using some CPU cycles... ... Edit: In a full hor. and ver. scrolling Screen, it's exactly 576 Bytes, and for the full height 720 bytes. The Gamescreen of Turrican is approx. 400 bytes then... on the Atari... with hor. Scrolling 480 Bytes Edited February 5, 2015 by emkay Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted February 5, 2015 Share Posted February 5, 2015 You can also do the two charset trick, if you don't mind an extra 1K for your font ... every second character line is a DLI which points to the lower half of the character set. So you'd do an LMS on every second line, pointing back to the start of the previous char. line, then set the DLI on that line to point to the second character set. Repeat down the screen. The offshoot of this, is you essentially have a 40x12 character mode, with each character being 4x16. The second char set esentially forms the bottom 8 lines of each character. 1 Quote Link to comment Share on other sites More sharing options...
Creature XL Posted February 6, 2015 Share Posted February 6, 2015 .... maaaaannnnn..... Turrican on the C64 is also build on different programming "tricks" and sub routines. The vertical scrolling doesn't stop, so the Displaylist management has the full control on how a DLI can get started, which means : What you see on the Screen is always fully placed right into the scene. POKEY timers weren't much helpfull there. The important parts were: One Charset is enough to fill the whole screen, when using "gr. 13" . Screen handling gets also rather low, AND you get some more cycles compared to gr. 12 ... You could trigger any DLI by pointing to the DLI Adresss and start the DLI where it has to start. No Problem there, if a DLI uses 1/3 of the screen, because 800-960 Bytes fill the screen, and the parallax is done by an additional change of the charset.... using some CPU cycles... ... Edit: In a full hor. and ver. scrolling Screen, it's exactly 576 Bytes, and for the full height 720 bytes. The Gamescreen of Turrican is approx. 400 bytes then... on the Atari... with hor. Scrolling 480 Bytes I have no clue what you are telling me here. I don't even know what Graphics 13 is. What I wanted to say was, that when using char mode, you can start a DLI every 8th line and not on an specific scan-line. If you want to do it, you need POKEY timer at 15KHz. If I happen to miss a trick or two how you can have "real" raster-IRQs on the A8 without POKEY-timers I am all ears. Maybe stuff would be clearer if you coded up examples of all the stuff you say. Yeah Yeah I know, you do not have time to code you are so busy. But then I wonder how many posts can you do in your free time? If you spend time coding, you would make less posts (removing noise from the forum). The big PLUS would be, that everybody would read your posts about ideas how WE (the actual coders) should do things, with more attention. 1 Quote Link to comment Share on other sites More sharing options...
emkay Posted February 6, 2015 Share Posted February 6, 2015 I have no clue what you are telling me here. I don't even know what Graphics 13 is. Antic Mode 5 What I wanted to say was, that when using char mode, you can start a DLI every 8th line and not on an specific scan-line. If you want to do it, you need POKEY timer at 15KHz. If I happen to miss a trick or two how you can have "real" raster-IRQs on the A8 without POKEY-timers I am all ears. What's the special trick with DLIs? Maybe stuff would be clearer if you coded up examples of all the stuff you say. Yeah Yeah I know, you do not have time to code you are so busy. But then I wonder how many posts can you do in your free time? If you spend time coding, you would make less posts (removing noise from the forum). The big PLUS would be, that everybody would read your posts about ideas how WE (the actual coders) should do things, with more attention. Sorry. This won't happen. Even IF I'd find the time for "Coding" , it wouldn't get any response. Best example is the POKEY Stuff.... more than a Decade posting what's needed and making demonstrations had been almost like talking to a wall. Quote Link to comment Share on other sites More sharing options...
+Stephen Posted February 6, 2015 Share Posted February 6, 2015 Sorry. This won't happen. Even IF I'd find the time for "Coding" , it wouldn't get any response. Best example is the POKEY Stuff.... more than a Decade posting what's needed and making demonstrations had been almost like talking to a wall. Untrue. I would certainly take a look. I've been welding for 25 years now. If all someone did was tell me how I should do something different to make it better, or complain that I was doing it wrong, you can bet I will shrug it off. If they actually show me, I will take notice. Same thing here. All talk with nothing to show is just that. Noise. 4 Quote Link to comment Share on other sites More sharing options...
Chilly Willy Posted February 7, 2015 Share Posted February 7, 2015 Untrue. I would certainly take a look. I've been welding for 25 years now. If all someone did was tell me how I should do something different to make it better, or complain that I was doing it wrong, you can bet I will shrug it off. If they actually show me, I will take notice. Same thing here. All talk with nothing to show is just that. Noise. No, it isn't. It's not the same at all. Programming is a highly mental task, and many aspects can simply be conferred through suggestions and code snippets and the like. I don't need to make an entire program to tell someone how to do an integer multiply and divide on the 6502, nor make a program to demonstrate using DLIs as opposed to POKEY timers. You just TELL THEM. 1 Quote Link to comment Share on other sites More sharing options...
Creature XL Posted February 7, 2015 Share Posted February 7, 2015 n No, it isn't. It's not the same at all. Programming is a highly mental task, and many aspects can simply be conferred through suggestions and code snippets and the like. I don't need to make an entire program to tell someone how to do an integer multiply and divide on the 6502, nor make a program to demonstrate using DLIs as opposed to POKEY timers. You just TELL THEM. All I demanded was a code snippet from someone who says since years how easy it is to do stuff on the A8. Not a fully working game, just the effect or trick or whatever. I know a bit about coding on the A8. Not as much as others here, but a lot more then some guys who claim to know who it works. Regarding your example, would you want me to proof when I tell you you can code a 32-bit integer division on the 6502 ( @1,7 MHz) as fast as on the 68060 (@60MHz) or would you just do it? I can even give you example code for the m68k version. But the 6502 is totally up to you. divu.w d0,d1 // around 36 cycles HF PS: Nice. I searched for 060 and cycles and found this http://alive.atari.org/alive12/30vs60.php good times 2 Quote Link to comment Share on other sites More sharing options...
emkay Posted February 7, 2015 Share Posted February 7, 2015 All I demanded was a code snippet from someone who says since years how easy it is to do stuff on the A8.Not sure who said or wrote that it is easy to do stuff with the A8. What I try to explain with my writings is how to avoid unneccessary hurdles. But problems seem to start by not understanding such simple sentences as "I don't find the time to code on the A8" ... Quote Link to comment Share on other sites More sharing options...
+playsoft Posted February 7, 2015 Share Posted February 7, 2015 popmilo, on 02 Feb 2015 - 06:36 AM, said: We can't yet see what he's working on i guess ? Would be good to get one of these 'universal' sprite multiplexers out in public so more people could use them in their games... I'm not sure about it being a universal sprite multiplexer but attached is my code. I'd done nothing on the A8 for over 20 years, happened to see Crownland on youtube and couldn't believe it. That was the impetus for seeing if I could do something similar with the sprites. It's based on what I knew back then, the usual interrupt to update the registers each character row. I have a draw list (actually two, one for each player pair) which for each row indicates which sprite (if any) occupies that space. It's double buffered and each frame the non-active draw list is cleared and a pass made over all the sprites in a random order. If all the character rows a sprite needs are free, it books them. Otherwise it tries the draw list for the other player pair - if that is not free then the sprite is not displayed. Next frame the same process occurs but as the sprites are processed in a random order hopefully it's not always the same sprite being dropped when a conflict occurs. In demo1 it uses a DLI, in the others it uses a Pokey timer. I swapped when I started vertically scrolling but that was probably unnecessary as I could have just adjusted the first screen row based on the vscrol offset. As the interrupt updates a number of registers I leave the top two lines of sprite data empty. Initially I used Pokey in 15kHz mode for accurate screen timing but I was unable to come up with any satisfactory sound effects. So I switched to 64kHz and approximated the screen position by alternating between waiting too long and then too short a time. The two blank lines at the top of the sprite seem to give me enough wiggle room (the demo released in July uses 64kHz Pokey http://atariage.com/forums/user/16447-paul-lay/ ). The 3 demos folders are all buildable using cl65. This was the first time I'd ever built A8 code on a PC and you can see that it wasn't until demo3 that I'd figured out how to do it with no C code present at all. The other folder contains the current multiplexer code I am using in the ongoing cart version. sources.zip 5 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.