Wrathchild Posted July 25, 2002 Share Posted July 25, 2002 Can anyone describe an efficient (in terms of redraw time as opposed to space) way of holding sprite data in RAM along with the algorithm for drawing them? I guess there's two approaches, one using a mask and one where the background color is thought of as transparant? I haven't studied them yet, but Zybex and Draconus are two examples of the sort of thing I mean. Regards, Mark Quote Link to comment Share on other sites More sharing options...
DanBoris Posted July 26, 2002 Share Posted July 26, 2002 What system are we talking about? As a general note to anyone who posts a programming question, please indicate (preferably in the subject line) which system you are talking about. I've read more then one message here where it took me a while to figure out what system was being discussed. Dan Quote Link to comment Share on other sites More sharing options...
Jetboot Jack Posted July 26, 2002 Share Posted July 26, 2002 Dan, Since Zybex and Draconus are 8bit Atari computer titles I think its safe to assume which system Wraithchild is talking about... sTeVE Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted July 28, 2002 Author Share Posted July 28, 2002 Point taken Dan, indeed it is the 8-bit Ataris that I'm refering too Quote Link to comment Share on other sites More sharing options...
Sheddy Posted August 27, 2002 Share Posted August 27, 2002 AFAIK Zybex and Draconus aren't doing anything that smart. They are both in character modes. The aliens in Zybex are just redefined characters. Notice how they don't move that smoothly or overlap other aliens or the background much. That is harder to do in a character mode than a graphics mode I expect you all know most of this already, but here's a common way of doing graphics mode software sprites. It may not be the fastest possible way but it's not that slow (Zone Ranger does it quicker with some self modifying code . See programming topic "Timepilot Technical discussion and help needed" for some insight on how it does it ): Data for the sprites is taken as a rectangle as wide as the widest part and as long as the longest part of the sprite. A faster routine can be written if you draw all your sprites in a fixed size rectangle. Let's use a 4 colour mode with 4 pixels per byte and assume a sprite of 16 pixels wide by 16 lines high. This is stored as just a string of 64 bytes, one line straight after the other in memory. Let's say the graphics screen is 40 bytes wide (standard Atari width). All the routine needs to do is copy the bytes to the screen, then at the end of each line make an adjustment to the screen memory address (add 40 less the sprite width), and just carry on copying. To get the sprites to overlap the quickest way is to just to "eor" the screen data and the sprite data together. The colour of the overlap is not always perfect, but it looks ok. Apart from speed the other bonus of "eor" is that you don't need to redraw any background graphics. Just draw them in reverse order, and the background is magically restored! (The Zone Ranger topic has a post on how to do a "proper" overlap with masks too) To get the sprites positioned to pixel accurracy, it is quickest to have 4 different versions drawn, pre-shifted one pixel further over in each version, rather than try and shift them real-time. Some unrolled code might look something like this for a 4 byte wide sprite.... Assume screen address for drawing sprite at is in zp screen and screen+1 and sprite data address is in zp sprite and sprite+1 clc ldy #0 lda (screen),y eor (sprite),y sta (screen),y iny lda (screen),y eor (sprite),y sta (screen),y iny lda (screen),y eor (sprite),y sta (screen),y iny lda (screen),y eor (sprite),y sta (screen),y ; line 0 drawn iny lda screen adc #screen width - sprite width sta screen bcc skip inc screen+1 clc skip: lda (screen),y eor (sprite),y sta (screen),y iny lda (screen),y eor (sprite),y sta (screen),y iny lda (screen),y eor (sprite),y sta (screen),y iny lda (screen),y eor (sprite),y sta (screen),y ; line 1 drawn iny lda screen adc #screen width - sprite width sta screen bcc skip2 inc screen+1 clc skip2: ....etc. Repeat for every line to draw. See the adjustment for screen width is quite involved? That's why some demo writers like to setup the screen as lines of 256 bytes wide. All you need then is to use just an "inc screen+1" Hope this helps. Chris BTW, for larger "solid" (not seethrough) objects, a method similar to filling a polygon with texture can be quicker than doing an "eor" or mask on every byte. I found this to be helpful for the space harrier demo draw routines. Quote Link to comment Share on other sites More sharing options...
Jetboot Jack Posted August 28, 2002 Share Posted August 28, 2002 Chris, If you run Zybex or Draconus under Atari800win - and in the monitor do a DLIST - you'll see the play screens are built from Antic D modelines... But I think these games could have been done better and more colorfully (dontcha HATE 3 shades of one color games) using Antic 4 - since not a lot of objects move around to be honest... sTeVE Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted August 28, 2002 Share Posted August 28, 2002 yeah.... i was suprised that draconus and zybex used "graphics 7" instead of charmode...but they are ok... average shooter etc... i guess it was easier to convert the c64 original....(haven't seen that one... maybe they do not exist on c64?) but still quite fast for a "highres" action game... but i still prefer "dropzone" like approach for shooters... draconus could be made like "timepilot" etc... as there is no scrolling envolved. but i believe that they wanted to have pixel 1:1 ratio... hve Quote Link to comment Share on other sites More sharing options...
Jetboot Jack Posted August 28, 2002 Share Posted August 28, 2002 Hve, Since the C64 versions of Zybex and Draconus are done in char mode - with hardware sprites for all moving objects - I see no reason why the 8bit version of Draconus was done in mode 7 - I think its safe to assume that they used the system they did because they had developed it for one title (Zybex) already... Interestingly enough Ninja COmmando (a later release from the same team/company) does use Antic E - and is noticably slower than the C64 version... I do think Draconus is a very nice game - it was released at full price on the Atari - only budget on the C64 - UK Atari owners were software starved... I still hold Henry's House (and in fact anything by Chris Murray) up as examples of how games could be coded for the 8bit that could be visually far better than the C64 - if programmed correctly. His Last Guardian really shows in some areas (not the asteroid section!) how a well designed 8bit program just using hardware sprites and char mode can really look impressive... sTeVE Quote Link to comment Share on other sites More sharing options...
Sheddy Posted August 28, 2002 Share Posted August 28, 2002 Doh! Well that will teach me for not checking! Zybex and Draconus sure look like Antic 4 games - would have thought they could have looked better than they do. I thought you guys were going to pick me up on fact that the code for 256 byte lines "inc screen+1" won't work with the example code ....it would have to be a "256+sprite width" wide screen to work right (or is it 256 - sprite width?)- or recoded somehow Chris Quote Link to comment Share on other sites More sharing options...
Jetboot Jack Posted August 28, 2002 Share Posted August 28, 2002 I'd love to learn more about raster sprites - I never did any of that kind of stuff beyond a few awful tests - always hardware PMG and char modes for me... Given how great the Space harrier demo looks I guess you've gotten a really good grasp of them Chris Looking at games like Gremlins and Donkey Kong only makes me want to use them more!!!! sTeVE Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted August 29, 2002 Author Share Posted August 29, 2002 To get the sprites positioned to pixel accurracy, it is quickest to have 4 different versions drawn, pre-shifted one pixel further over in each version, rather than try and shift them real-time. This is exactly a problem I'm toying with. The 'Barbarian' (Palace) C64 warrior sprites can be done as software sprites on the Atari but you'd need to shift them before drawing. Due to the number of poses (the graphics take up nearly 16K) 4 versions of each wouldn't be practical (unless I use a bank switching ROM ) Therefore shifting is the only option... perhaps I'll have a look into System 3's International Karate for some clues... Are the IK+ guys on this forum? Maybe they could share a few tips. Regards, Mark Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted September 1, 2002 Share Posted September 1, 2002 well... have a look on the IK+ conversion page... IK on atari rocks!... (i can not find the webadress right now...) ´sad that archer mclean did just 2 games... pastfinder on atari is also a very good way to do colorfull game (the activision version)... hve Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted September 2, 2002 Author Share Posted September 2, 2002 I've a sneaking feeling that Barbarian (and maybe IK) ensure that their animations resolve on a character alignment, i.e. 4 pixels. This gets around the problem of having to shift the whole software sprite. I'm yet to confirm this, but a few screenshots from an emulator should be the easiest way to do so... only one case to disprove the theory. :wink: Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted September 2, 2002 Share Posted September 2, 2002 http://www.uce.pl/ikplus/ Quote Link to comment Share on other sites More sharing options...
Sheddy Posted September 4, 2002 Share Posted September 4, 2002 I've a sneaking feeling that Barbarian (and maybe IK) ensure that their animations resolve on a character alignment, i.e. 4 pixels. This gets around the problem of having to shift the whole software sprite. Unfortunately, I wouldn't count on it...the C64 is using its great hardware sprites, which have no respect for such limitations! But this does sound like a good compromise, which could work, if not going for huge carts. 16k for just the barbarian!....so all 64k for 4 shifted versions...jeez! A spite draw with real-time shift would be about 3 times slower than one without shift. May still be quick enough though to run in 60/50fps (or certainly 25/17 fps). The sprites are large but not that huge on Barbarian, and there's only a couple at once. Only other things I can think that might help (a bit).... decompress the other baddies into their shifted versions only when they are needed next. maybe the barbarian can be broken down into smaller chunks. some of the chunks may not change during certain animation. You could re-draw it so that was the case if necessary (lot of work though!) You could lose some frames of animation. Big sacrifice, and C64 owners would have an excuse to laugh. Can't think of anything else now Looks like the IK+ guys don't hang here. They haven't got the English version of their site up yet, so how's your Polish? Chris Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted September 4, 2002 Share Posted September 4, 2002 as far as i can remember the movement of the fighters were not so smoth... so it could work on atari with 2 pixel steps... but there is a polish official game conversion from barbarian... get it from here... http://homepages.paradise.net.nz/atari/g.html hve Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted September 4, 2002 Author Share Posted September 4, 2002 the C64 is using its great hardware sprites Nope, it appears to be a software sprite... and they designed them nicely to not require shifting... clever buggers! how's your Polish? My wife's Czech so she is able to translate a few things for me but there is a polish official game conversion from barbarian... But its horribly unplayable... only 4 colours... and I miss the snakes! Regards, Mark K. barb.zip Quote Link to comment Share on other sites More sharing options...
Sheddy Posted September 4, 2002 Share Posted September 4, 2002 Nope, it appears to be a software sprite...and they designed them nicely to not require shifting... clever buggers! (...sigh) another DOH! for me then - 2 in 1 topic - impressive, even for me! Must get the C64 emu up and working again since the move to XP... What are they using the sprites for then? (can't imagine them not using them in a C64 game!) Can your lovely wife work out when we're likely to see any more IK+? Try showing her the icons post to show how much you care about her and appreciate her translation talent (or just use it as emotional blackmail ) J/K! Chris Quote Link to comment Share on other sites More sharing options...
Jetboot Jack Posted September 5, 2002 Share Posted September 5, 2002 Mark, Are yoo 101% sure that Barbarian donesn't use HW sprites on the C64 version for the fighters... I'm pretty certain (well as certain as I can be) that it does use sprites for the men, especailly since the backdrops use a mix of charmodes (mono mode on some of the later levels for extra detail) and the extended color mode too - which would affect the software sprites, but which the men pass over untouched. Also I noticed that the 4 color per char limit would be exceeded in many places where man and background cross... So if I'm wrong let me know, but I'm convinced the game uses the "easy" route sTeVE Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted September 5, 2002 Share Posted September 5, 2002 i strongly believe that barbarian use definitly hardware sprites... they would be stupid not to do... the gnome, etc... all has kind of "spritisch" look... hve ps. ik uses charmode... Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted September 5, 2002 Author Share Posted September 5, 2002 Definitely software sprites for the guys, the A8 demo uses almost the same routines Two 256 byte tables are set up, one for masks and one for 4 colour bit pair flipping. The draw routine is therefore an AND/OR of the MASK/DATA onto the background. The 2nd players jacket is a hw-sprite, along with the blood splats and the servant. Long long ago I had this little demo on a disk I sent to sTeVE! IK on the Atari didn't have to contend with any background and so the character mode worked well. I've used the same character mode for the Barbarian demo as it better models the C64 screen layout. Multiple charsets and DLIs could be used to produce the full display (and is preferable to get a 5th colour) but raster mode is probably easier to work with. One thing I have to work out is where the guys head comes from when he jumps... they seem to 'tack' this on afterwards as it isn't part of the normal data?! Also, the background colour is not black, therefore I might rework the data and/or draw routine so that I can have a black border. Rgds, Mark servant.zip Quote Link to comment Share on other sites More sharing options...
Jetboot Jack Posted September 5, 2002 Share Posted September 5, 2002 Sorry Mark you've lost me - A8 demo??? sTeVE Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted September 6, 2002 Author Share Posted September 6, 2002 Sorry for the confusion, I was referring to the demos previously sent in this thread. To rectify the situation I've managed to resolve the bit masking issues, used Mode 4 and also pinched some background scenery to demonstrate over. The demo works by showing the sprite components in the top half and the animation in the lower half. After the animation has cycled (~90 poses) the top half shows the next set of tiles (8 pages in all ). Sorry about the flickering, I'll add buffering later... (I'm supposed to be getting back to Elite!) Regards & Enjoy, Mark barb.zip Quote Link to comment Share on other sites More sharing options...
Sheddy Posted September 7, 2002 Share Posted September 7, 2002 Neat! Like how you've got all the overlaps working right in Antic 4. Without plowing through the code, any tips you can share on the best ways to do this? I assume all of the Barbarian is chars that get redefined every frame? How many you have to use - there'll be enough left for other baddies? Chris Quote Link to comment Share on other sites More sharing options...
Sheddy Posted September 7, 2002 Share Posted September 7, 2002 Definitely software sprites for the guys, the A8 demo uses almost the same routines Two 256 byte tables are set up, one for masks and one for 4 colour bit pair flipping. The draw routine is therefore an AND/OR of the MASK/DATA onto the background. Mark, what is the "4 colour bit pair flipping" table used for. I get the mask one, but what's that one used for? For flipping left/right? Cheers Chris 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.