Looking for Sound/Graphics C/C++ libraries

C and PASCAL (or any other high-level languages) in here please

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

master
Atariator
Atariator
Posts: 17
Joined: Sat Aug 11, 2007 7:49 pm

Postby master » Wed Aug 15, 2007 7:54 pm

Nyh wrote:Unless your name is Nic Thisell don't even start to think about using multiple palettes in one scanline for arcade games. Color switching within a scanline is high magic and processor intensive. First start with playing around with sprites and maybe some raster interrupts. You will soon discover it is hard enough.
Sure, for start, just getting something on screen will be fine. While I understand that switching palette during one scanline is complicated, I`m pretty sure, that basic palette switching (just once per scanline) shouldn`t be fundamentally different from Atari 800 XL`s Display List Interrupt method. Sure, it`s been ~20 yrs since I did that effect, but the principle wil be probably the same - I don`t believe Atari invented something totally different when they switched to 16-bit platforms, especially for something so low-level.
Though, I could be wrong here, so please feel free to correct me.

Nyh wrote:BTW: with movem.l you can do 3 complete color switches in one scanline giving you a maximum of 64 colors on one scanline leaving you still 32 clock ticks at the end of the scanline enough for 3 extra colors to change so a grand total of 67 colors on a scanline is possible.
That`s just crazy - 67 colors 8O ! This also means, that the CPU is just drawing the picture - nothing else, right ?

User avatar
unseenmenace
Atari God
Atari God
Posts: 1961
Joined: Tue Sep 21, 2004 9:33 pm
Location: Margate, Kent, UK
Contact:

Postby unseenmenace » Wed Aug 15, 2007 8:14 pm

master wrote:So, that`s 6 KBs per 16x16 chunk. Say, I need 6 chunks per one animation frame of my character (32x48), i.e. 36 KBs per animation frame. I`ll eat up 0.1 MB of memory with just 3 frames. If I wanted at least 4 animations (Breathe,Walk,Attack,Death) with at least 5 frames per each, that would be 5x4x36 = 0.7 MB per character.
So, that`s impossible unless I limit it to emulator use, where I heard it`s possible to use 4 MB of RAM (if I heard correctly). Though that would sort-of kill the original idea of a game runnable on regular Atari 1040 ST.
How many people have upgraded their Atari to 4 MBs ? Would that annoy many people if the game wanted 4 MB of RAM ? Or maybe, I can altogether just forget this issue and take 4 MB for granted ?

Thats only if you are using pre-shifted sprites where you have multiple copies (2, 4, 8 or 16) of the same sprite image at different horizontal pixel positions so that the program doesn't have to horizontally shift the sprite data in real-time (something the 68000 is rather slow at). If your game doesn't need to have a high framerate then you can dispense with the preshifting in which case a 32 x 48 masked sprite is only 960 bytes.
One trick I am using for some of my animated sprites is to shift each frame of animation along from the last so that a different frame gets displayed according to the horizontal position of the sprite (within each 16-pixel column). This is only applicable to certain types of animation such as walking. Below is an example of this with the Turrican II World 1 fish sprite waggling its tail as it moves along:-
You do not have the required permissions to view the files attached to this post.
UNSEEN MENACE
Several STFM's, 4MB STE, 2MB TT with 1.2GB Hard Drive and 14MB Falcon with 540MB Hard Drive,
Lynx 2 and Jaguar with JagCD
Member of GamebaseST and AtariLegend team
Check out my website at http://unseenmenace.110mb.com

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Postby Nyh » Wed Aug 15, 2007 8:53 pm

master wrote:
Nyh wrote:If got very decent sprite routines with preshifted data, you can do 44 different masked 16x16 sprites with 16 colours.
This is the data that I wanted to hear ! However, it seems a little bit low to me at first sight, but I`m not yet familiar with the platform.
To put it into other perspective, 16x16x44 = 11264 pixels. Which is almost the same as 32x70x5 (I want tall sprites, maybe not 32x70, but close to it). But this would mean that I`d be able to change only 5 frames per second. That is, if I understand the data above correctly, and they mean the performance (16x16x44) per second.

On an Atari you don't count the number of pixels in a sprite but the number of words. The 9 pixel on a low resolution Atari screen is made up from bit nr 6 of the 1st word, bit nr 6 of the 2nd word, bit nr 6 of the 3rd word and bit nr 6 of the 4 th word. A pixel has also 4 bitplanes, 16 different values so one color of a palette from 16. With the 32 bit registers of the 68000 you can work at 2 words of screen memory at the same time. Because of the word wise organization of the screen memory a 16 bit wide sprite usually is in 2 x 4 words of screen memory, unless it is exactly aligned with a word, then it takes only 1 x 4 words.

You don't understand the data correctly, the performance is in number of sprites per VBL (Vertical BLank) at 50 Hz, ie 50 frames per second. For your 32 bit wide sprites you need about 336 clocks per line so for a 32x70 sprite you need 23520 clocks. Given 160000 clocks per VBL you can do 6 sprites of that size in 1 VBL (50 frames per second).

master wrote:
Nyh wrote:A single 16x16 preshifted sprite uses 4 kB memory for the sprite data and 2 kB memory for the mask data.
So, that`s 6 KBs per 16x16 chunk. Say, I need 6 chunks per one animation frame of my character (32x48), i.e. 36 KBs per animation frame. I`ll eat up 0.1 MB of memory with just 3 frames. If I wanted at least 4 animations (Breathe,Walk,Attack,Death) with at least 5 frames per each, that would be 5x4x36 = 0.7 MB per character.

For a preshifted sprite you will need:
bytes=16*(number_of_ words+1)*12*number_of_lines
For a 32x48 sprite you will need (32 pixels is 2 words):
bytes=16*(2+1)*12*48=27kB
You can safe a lot of memory by not preshifting a sprite at 16 pixels, but only 8, cutting memory usage in half, but the sprite then only can be placed at even pixel positions.

master wrote:So, that`s impossible unless I limit it to emulator use, where I heard it`s possible to use 4 MB of RAM (if I heard correctly). Though that would sort-of kill the original idea of a game runnable on regular Atari 1040 ST.
How many people have upgraded their Atari to 4 MBs ? Would that annoy many people if the game wanted 4 MB of RAM ? Or maybe, I can altogether just forget this issue and take 4 MB for granted ?

No, you can take 1 Mb for granted.

master wrote:
Nyh wrote:Note there is no time alloted for restoring the background, building the playfield or clearing the screen...
That`s actually great, because you provided me with data under extreme cirumstances, so I`ve got a fantastic reference point to measure with. And, most importantly, to set my initial expectancies quality and performance-wise.

There are some possibilities to get some more speed by clever use of movem to load data into registers but I didn't allot any time for setup and sprite management. So I think my calculations are pretty close to the upper limits.

master wrote:A little rant - this is pretty different from PC world, where I`m used to polygonal characters which can compress fantastically. My current compression ratio is around 12:1, since vectors are easily quantizable. Plus, I have interpolation between frames, so the smaller amounts of frames changes just the perception of quality, but not the actual quality - it`s always smooth.
Here, it`s different. I can`t interpolate between 2D frames. Sure, I could store just the data that are different, but if I limit myself to just 4-5 frames per animation, there`s little amount of RAM that I`ll reuse between frames anyway - the actual frames are going to be pretty different one from another.

Yes, on the Atari it is an entirely different ballgame. Not a lot of memory and not a lot of processor cycles to be burned. Although the amount of memory is huge compared to the good old ZX Spectrum or C64, it is just small compared to the amount of memory in modern PC's. The secret of a good game is not a huge amount of eye candy but a good game play.

master wrote:Any ideas, besides lowering the size of sprites ?

Cheat, cheat a lot without the user noticing it. Use less colors, limit sprite sizes and possible sprite positions in clever ways, go for simplicity and fun.

Look at games of Jeff Minter and understand what I am talking about. Playability is not proportional with sprite size, usually it is the other way around.

Hans Wessels

master
Atariator
Atariator
Posts: 17
Joined: Sat Aug 11, 2007 7:49 pm

Postby master » Wed Aug 15, 2007 8:54 pm

unseenmenace wrote:Thats only if you are using pre-shifted sprites where you have multiple copies (2, 4, 8 or 16) of the same sprite image at different horizontal pixel positions so that the program doesn't have to horizontally shift the sprite data in real-time (something the 68000 is rather slow at). If your game doesn't need to have a high framerate then you can dispense with the preshifting in which case a 32 x 48 masked sprite is only 960 bytes.
A ratio of 6:1 completely changes the picture - it`ll allow me to render more frames for each animation. Though, it remains to be seen how fast will it actually be. But at least there`s some option.
One advantage I have is that I can create the sprites fast and easily due to them being rendered in my 3d modelling program. So if I need to change their dimension, it`s a question of an hour or two at most, whereas if my sprites would be 2D (regular pixel art), it would be impossible to resize them.

unseenmenace wrote:One trick I am using for some of my animated sprites is to shift each frame of animation along from the last so that a different frame gets displayed according to the horizontal position of the sprite
Interesting idea, indeed.


Hm, I just had an idea - the walk animation cycle would start and finish by 16 pixels multiplies. Thus it would be guaranteed that the later Breathe/Attack/Death animation wouldn`t have to be preshifted since they would always start at multiply of 16. So only Walk animation would be preshifted (or maybe not at all - I`d have to see the performance difference by myself to decide if it`s worth the memory footprint),
Sure, it remains to be seen if it would look acceptable, but it would solve the memory footprint issue for sure.

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Postby Nyh » Wed Aug 15, 2007 9:06 pm

master wrote:Sure, I`ll start with regular sprites first, but it`s great that I already learnt about what can I expect from the platform. It definitely doesn`t match with my expectations - I thought that Atari ST is much faster platform - my bad.

That is part of the fun, doing things on the machine that are at first glance impossible.

master wrote:I completely forgot the music ! How much can I expect it to take from my performance ?

The music you were thinking of will use all processor time at its own. On a normal Atari ST forget about playing MODs, even digisound at a low quality is processor expensive (need to setup a timer interrupt to make the processor play your sample at the sample rate, i.e. 16 kHz digisound means 16000 interrupts per second or 16000/50 = 320 interrupts per vbl. Use about 100 clocks to service the interrupt and playing the digisound. 320*100 = 32000 clocks for your digisound per VBL. Remember you had only 160000 clocks per VBL so you burned 32000/160000 = 20% of your processor time playing the music. I am afraid you will have to stick to chip music. Needing some where between 32 and 3000 clocks depending on the music and the amount of RAM you wish to use for the music.

Hans Wessels

master
Atariator
Atariator
Posts: 17
Joined: Sat Aug 11, 2007 7:49 pm

Postby master » Wed Aug 15, 2007 9:18 pm

Nyh wrote:On an Atari you don't count the number of pixels in a sprite but the number of words. The 9 pixel on a low resolution Atari screen is made up from bit nr 6 of the 1st word, bit nr 6 of the 2nd word, bit nr 6 of the 3rd word and bit nr 6 of the 4 th word. A pixel has also 4 bitplanes, 16 different values so one color of a palette from 16.
You don't understand the data correctly, the performance is in number of sprites per VBL (Vertical BLank) at 50 Hz, ie 50 frames per second. For your 32 bit wide sprites you need about 336 clocks per line so for a 32x70 sprite you need 23520 clocks. Given 160000 clocks per VBL you can do 6 sprites of that size in 1 VBL (50 frames per second).
Thanks for the explanation 8) I assume that those 160.000 cycles are calculated as 8 MHz / 50 frames, right ?
I`m still confused how does the background (made of static sprites) affect the performance. Does it take up from those 160.000 cycles too ?

Nyh wrote:For a preshifted sprite you will need: bytes=16*(number_of_ words+1)*12*number_of_lines. For a 32x48 sprite you will need (32 pixels is 2 words): bytes=16*(2+1)*12*48=27kB
You can safe a lot of memory by not preshifting a sprite at 16 pixels, but only 8, cutting memory usage in half, but the sprite then only can be placed at even pixel positions.
Great formula - I`ll count the mem usage more precisely now. Does it feel like "jump" if I omit one pixel, or is it not actually visible ?

Nyh wrote:No, you can take 1 Mb for granted.
Yes, on the Atari it is an entirely different ballgame. Not a lot of memory and not a lot of processor cycles to be burned. Although the amount of memory is huge compared to the good old ZX Spectrum or C64, it is just small compared to the amount of memory in modern PC's. The secret of a good game is not a huge amount of eye candy but a good game play.
I`m not trying it compare to current PCs per se - more to older 286/386 PCs. Of course it`s huge step forward compared to my old Atari 800 XL which had just 64 KBs. Surely, I`m not the one who can say that 640 KBs is enough for him :lol:

Nyh wrote:Look at games of Jeff Minter and understand what I am talking about. Playability is not proportional with sprite size, usually it is the other way around.
Pardon my ignorance, but could you name few of his games ? Regarding gfx vs gameplay issue - I understand this eternal battle, but if the game will suck, at least the gfx shall be pretty :D

master
Atariator
Atariator
Posts: 17
Joined: Sat Aug 11, 2007 7:49 pm

Postby master » Wed Aug 15, 2007 9:30 pm

Nyh wrote:The music you were thinking of will use all processor time at its own. On a normal Atari ST forget about playing MODs, even digisound at a low quality is processor expensive - 32000 clocks for your digisound per VBL. Remember you had only 160000 clocks per VBL so you burned 32000/160000 = 20% of your processor time playing the music. I am afraid you will have to stick to chip music. Needing some where between 32 and 3000 clocks depending on the music and the amount of RAM you wish to use for the music.
Definitely ! Plus, since I`m not going to loose time coding sound library (I`m willing to write ASM code just for gfx routines), just using what RG provides, I have no impact on how it performs, so I`ll just have to stick with whatever performance it provides.

Still, I was afraid, that the digisound eats much more CPU time, not just about 20%, so it could be usable during Main menu/Map/other sections of game where performance is not so critical.
On the other hand, those 20% may be from some extremely optimized ASM code, so then it does make sense.

Time to google up some free lousy MIDIs :D
Or is anyone actually still composing the music for Atari ST these days, as a hobbyist ?

User avatar
unseenmenace
Atari God
Atari God
Posts: 1961
Joined: Tue Sep 21, 2004 9:33 pm
Location: Margate, Kent, UK
Contact:

Postby unseenmenace » Wed Aug 15, 2007 9:54 pm

master wrote:Still, I was afraid, that the digisound eats much more CPU time, not just about 20%, so it could be usable during Main menu/Map/other sections of game where performance is not so critical.

You can probably still have sampled sound effects without too much CPU usage as much lower sampling rates are usually acceptable for simple sounds like bangs and crashes but not so good for speech. You are certainly right that having proper digi music in the menu's and such is a doable idea.

master wrote:Or is anyone actually still composing the music for Atari ST these days, as a hobbyist ?

Actually there is still quite a bit of YM music activity, have a look at the YM Rocking section of the forum. Incidentally YM refers to the ST's sound chip, the Yamaha YM2149.
UNSEEN MENACE
Several STFM's, 4MB STE, 2MB TT with 1.2GB Hard Drive and 14MB Falcon with 540MB Hard Drive,
Lynx 2 and Jaguar with JagCD
Member of GamebaseST and AtariLegend team
Check out my website at http://unseenmenace.110mb.com

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Postby Nyh » Wed Aug 15, 2007 10:01 pm

master wrote:Thanks for the explanation 8) I assume that those 160.000 cycles are calculated as 8 MHz / 50 frames, right ?
I`m still confused how does the background (made of static sprites) affect the performance. Does it take up from those 160.000 cycles too ?

Yes, there is only the processor doing work for you. Not some magic hardware. The screen in 32000 bytes long starting at a 256 byte boundary in memory. On a normal ST you can not scroll the display one pixel to the right or left, nor up or down (using syncscroll is not an option for you now). So you will have to create the background from somewhere. Normally it is build from 16x16 pixel tiles neatly aligned. You don't have enough processor time to rebuild the whole screen from those tiles in one vbl (you can come very close but then there is no processor time left for your sprites, I am using that trick in Heartland 2000 http://www.pouet.net/prod.php?which=21650, plus a lot of other tricks (it was written in C with assembly for the sprite routines, you can have the source if you are interested). You can copy the whole screen from a buffer. That will take about 69000 clock cycles or 42% of the processor time. Smarter is to restore only the parts of the screen you destroyed by drawing sprites, more administration to do but usually a lot faster.

master wrote:
Nyh wrote:Look at games of Jeff Minter and understand what I am talking about. Playability is not proportional with sprite size, usually it is the other way around.
Pardon my ignorance, but could you name few of his games ? Regarding gfx vs gameplay issue - I understand this eternal battle, but if the game will suck, at least the gfx shall be pretty :D

I like Llamatron of Jeff Minter a lot. It is (like all his games) a special experience:
http://www.llamasoft.co.uk/lc-16bit.php

Hans Wessels

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Postby Nyh » Wed Aug 15, 2007 10:23 pm

master wrote:Time to google up some free lousy MIDIs :D
Or is anyone actually still composing the music for Atari ST these days, as a hobbyist ?

No, no MIDI on the ST as for game music, you need chipsound. The world of chip music is a very interesting part of the ST scene. I am not a music programmer so I use ripped tunes from other games and demo's and to get conserve processor time I cheat a lot playing chiptunes. :-)

Hans Wessels

master
Atariator
Atariator
Posts: 17
Joined: Sat Aug 11, 2007 7:49 pm

Postby master » Thu Aug 16, 2007 6:39 am

unseenmenace wrote:You can probably still have sampled sound effects without too much CPU usage as much lower sampling rates are usually acceptable for simple sounds like bangs and crashes but not so good for speech.
Great idea ! The question is how will digitized sounds match with chip music, but that`s least of my problems, right now :)

unseenmenace wrote:Actually there is still quite a bit of YM music activity, have a look at the YM Rocking section of the forum.
Interesting. I have to admit, music is currently of least importance, it always was, since I`m not a composer and just use what I`ve been provided. But there`s lots of free usable music all over net, so I`ll just spend one day searching for something appropriate.

master
Atariator
Atariator
Posts: 17
Joined: Sat Aug 11, 2007 7:49 pm

Postby master » Thu Aug 16, 2007 6:59 am

Nyh wrote:Yes, there is only the processor doing work for you. Not some magic hardware. The screen in 32000 bytes long starting at a 256 byte boundary in memory.
So, basically, once something is written to VRAM, it doesn`t take any cycles to redraw, right ?

Nyh wrote:You don't have enough processor time to rebuild the whole screen from those tiles in one vbl (you can come very close but then there is no processor time left for your sprites
So, you`re basically saying, that redrawing whole background will take at least one second ? Isn`t that annoying for a player when switching screens from left to right ? Or is it possible to precreate the screen and just change the screen pointer (not sure, if that VRAM offset is fixed in HW) ?

Nyh wrote: I am using that trick in Heartland 2000 http://www.pouet.net/prod.php?which=21650, plus a lot of other tricks (it was written in C with assembly for the sprite routines, you can have the source if you are interested).
I`d be delighted if you were willing to share it and either attach it here or send me an email at "vrepcak AT seznam DOT cz" 8)

Nyh wrote: You can copy the whole screen from a buffer. That will take about 69000 clock cycles or 42% of the processor time.
So, that`s less than half a second, when player is switching screens. Should be less annoying than wait over one second. But still, I get a feeling that there is some other trick being used.

Nyh wrote: Smarter is to restore only the parts of the screen you destroyed by drawing sprites, more administration to do but usually a lot faster.
Yeah, that`s obvious. Sort-of GetImage/PutImage functionality of Pascal, here it`s aligned for words.

User avatar
unseenmenace
Atari God
Atari God
Posts: 1961
Joined: Tue Sep 21, 2004 9:33 pm
Location: Margate, Kent, UK
Contact:

Postby unseenmenace » Thu Aug 16, 2007 7:36 am

master wrote:So, basically, once something is written to VRAM, it doesn`t take any cycles to redraw, right ?

Correct

master wrote:So, you`re basically saying, that redrawing whole background will take at least one second ? Isn`t that annoying for a player when switching screens from left to right ?

Not one second, one VBL (screen redraw) which is 1/50th of a second

master wrote: Or is it possible to precreate the screen and just change the screen pointer (not sure, if that VRAM offset is fixed in HW) ?

Yes you can do exactly that if you are doing a flip screen type game rather than a scrolling one.
UNSEEN MENACE
Several STFM's, 4MB STE, 2MB TT with 1.2GB Hard Drive and 14MB Falcon with 540MB Hard Drive,
Lynx 2 and Jaguar with JagCD
Member of GamebaseST and AtariLegend team
Check out my website at http://unseenmenace.110mb.com

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Postby Nyh » Thu Aug 16, 2007 9:36 am

master wrote:
Nyh wrote:Yes, there is only the processor doing work for you. Not some magic hardware. The screen in 32000 bytes long starting at a 256 byte boundary in memory.
So, basically, once something is written to VRAM, it doesn`t take any cycles to redraw, right ?

There is no VRAM, only RAM. You set the registers of the shifter at an address and the shifter will display the data starting at that address on the screen. The LSB of the start of the video address is always zero (there is no register to write the LSB to), ie the video address starts at a 256 byte boundary.
master wrote:
Nyh wrote:You don't have enough processor time to rebuild the whole screen from those tiles in one vbl (you can come very close but then there is no processor time left for your sprites
So, you`re basically saying, that redrawing whole background will take at least one second ?

No, I am saying it takes one VBL, or one frame, 1/50 s.
master wrote:Isn`t that annoying for a player when switching screens from left to right ? Or is it possible to precreate the screen and just change the screen pointer (not sure, if that VRAM offset is fixed in HW) ?

You can precreate screens and change the screen pointer. It is called double buffering. Usually you use two screens, one being displayed and one being updated. This way there won't be flickering of parts of the screen being updated and displayed at the same time. But a game like Enchanted Land uses only one screen, sorts the sprites so they can be redrawn before they are displayed.
master wrote:
Nyh wrote: I am using that trick in Heartland 2000 http://www.pouet.net/prod.php?which=21650, plus a lot of other tricks (it was written in C with assembly for the sprite routines, you can have the source if you are interested).
I`d be delighted if you were willing to share it and either attach it here or send me an email at "vrepcak AT seznam DOT cz" 8)

File is attached. It compiles with Pure C (I just did a rebuild). The main routines are in HLAND.C. Sprite and screen drawing is in FSCREEN.S. Interesting is also the SCREEN.C file. This file is a relic from the time the whole game was written in C. During development the C code was replaced with (much faster) assembly. It is not possible to switch back to the C routines because the data structures changed to facilitate faster routines. Note: although the code looks simple there are some very tricky data structures used to make things fast. It is not easy to replace the map by a new one.

master wrote:
Nyh wrote: You can copy the whole screen from a buffer. That will take about 69000 clock cycles or 42% of the processor time.
So, that`s less than half a second, when player is switching screens. Should be less annoying than wait over one second. But still, I get a feeling that there is some other trick being used.

No, I am speaking in terms of one VBL. 1/50th of a second: 69000 clockcycles of 125 ns = 8.625 ms.

master wrote:
Nyh wrote: Smarter is to restore only the parts of the screen you destroyed by drawing sprites, more administration to do but usually a lot faster.
Yeah, that`s obvious. Sort-of GetImage/PutImage functionality of Pascal, here it`s aligned for words.

Something like that. As a game and demo coder I just see the screen memory as a piece of memory you have to copy data to and from. Because the importance of those copy routines for the total speed of the game it always pays off to write those routines in carefully optimized assembly. For every sprite size a own specialized routine. You can write generic sprite routines but they are never as fast as the specialized ones. However, generic sprite routines are easy to get started with. To workout concepts and explore possibilities.

Hans Wessels
You do not have the required permissions to view the files attached to this post.

master
Atariator
Atariator
Posts: 17
Joined: Sat Aug 11, 2007 7:49 pm

Postby master » Thu Aug 16, 2007 3:43 pm

Nyh wrote:No, I am saying it takes one VBL, or one frame, 1/50 s.
OK, that`s much better :)

Nyh wrote:You can precreate screens and change the screen pointer. It is called double buffering.
At least this is possible.

Nyh wrote:File is attached. It compiles with Pure C (I just did a rebuild).
Thanks 8)

Nyh wrote:You can write generic sprite routines but they are never as fast as the specialized ones. However, generic sprite routines are easy to get started with. To workout concepts and explore possibilities.
I`ll probably be more realistic about my actual time budget devoted to this game, so unless I`m extremely hooked up by the platform, I`ll probably stick with the general routines. But who knows ? I may get excited and devote whole weekend to sprite optimizations. Their only problem is that they must be done at one sitting. You can`t start optimizing and do it 2 hrs a day, because after 5 days you`ve got a mess of a code, which is anything but a code resembling 10hrs of work, if you know what I mean.
But gameplay issues are perfectly possible to settle within few hrs at one sitting.

User avatar
MaLICiouS
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 127
Joined: Tue Jun 05, 2007 4:01 pm
Location: Sweden
Contact:

Postby MaLICiouS » Fri Aug 17, 2007 7:50 am

If you're used to coding for other operating systems, such as GNU/Linux, windows and MacOS X, you can use SDL. Note that you'll either need FreeMiNT with GCC on the Atari side, or a GCC cross-compiler on the PC side.
Cross-compiled binaries are pretty large, though.
4MB 1040STe
4MB Mega/STE with FreeMiNT/XaAESm 40MB SCSI HD, 1.44M floppy
Recased Falcon030 with CT2, 64MB TT-RAM, 4MB ST-RAM, FreeMiNT/XaAES, EtherNEC and 40GB HDD

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 5089
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Postby simonsunnyboy » Fri Aug 17, 2007 8:11 am

SDL on Atari needs at least some accelerated Falcon. It is too slow for the ST.
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Postby Nyh » Fri Aug 17, 2007 3:24 pm

master wrote:I may get excited and devote whole weekend to sprite optimizations. Their only problem is that they must be done at one sitting. You can`t start optimizing and do it 2 hrs a day, because after 5 days you`ve got a mess of a code, which is anything but a code resembling 10hrs of work, if you know what I mean.

Optimized sprite code will not be a mess. Most of the time you spend figuring out the best combination of movem.l, move.l, and.l, or.l and xor.l. Smart data structures can help too like interleaving mask and sprite data so you can use a movem.l to load registers. When you have decided the best combination you unroll the loops by a lot of copy and paste, assembler macros or a code generator. See FSCREEN.S in heartland 2000. Copy and paste and assembler macro's to expand loops. Most of the magic is in the generated file BLOCKDATA.S.

Hans Wessels

User avatar
MaLICiouS
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 127
Joined: Tue Jun 05, 2007 4:01 pm
Location: Sweden
Contact:

Postby MaLICiouS » Fri Aug 17, 2007 7:24 pm

simonsunnyboy wrote:SDL on Atari needs at least some accelerated Falcon. It is too slow for the ST.

OK. I didn't know that. SDL won't cross compile for me. Now I don't have to try again. Thanks :)
4MB 1040STe
4MB Mega/STE with FreeMiNT/XaAESm 40MB SCSI HD, 1.44M floppy
Recased Falcon030 with CT2, 64MB TT-RAM, 4MB ST-RAM, FreeMiNT/XaAES, EtherNEC and 40GB HDD

cdoty
Retro freak
Retro freak
Posts: 11
Joined: Sat Feb 19, 2005 12:59 am
Location: Houston, TX
Contact:

Postby cdoty » Thu Aug 30, 2007 3:08 am

Nyh wrote:Optimized sprite code will not be a mess. Most of the time you spend figuring out the best combination of movem.l, move.l, and.l, or.l and xor.l. Smart data structures can help too like interleaving mask and sprite data so you can use a movem.l to load registers.


Was the compiled sprite idea ever used on the Atari ST, or do masks elminate the advantage of compiled sprites?

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Postby Nyh » Thu Aug 30, 2007 8:41 am

cdoty wrote:Was the compiled sprite idea ever used on the Atari ST, or do masks elminate the advantage of compiled sprites?

What do you mean by compiled sprites?

Hans Wessels

cdoty
Retro freak
Retro freak
Posts: 11
Joined: Sat Feb 19, 2005 12:59 am
Location: Houston, TX
Contact:

Postby cdoty » Thu Aug 30, 2007 12:47 pm

Nyh wrote:What do you mean by compiled sprites?


Sprites stored as the code necessary to blit them.

For example, data $FF, $00, $FF could be stored as:
move.b $FF, (a0)+
addq #1. a0
move.b $FF, (a0)+

(Skipping the $00 byte, and no mask needed).

Here's a better description:
http://www.nondot.org/~sabre/graphpro/sprite4.html

This is an old technique that I remember from the MS-DOS days, but I recently ran across it again while programming the Philips CD-I.
Last edited by cdoty on Thu Aug 30, 2007 3:05 pm, edited 1 time in total.

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Postby Nyh » Thu Aug 30, 2007 2:59 pm

cdoty wrote:Sprites stored as the code necessary to blit them.

For example, data $FF, $00, $FF could be stored as:
move.b $FF, (a0)+
addq #1. a0
move.b $FF, (a0)+

(Skipping the $00 byte, and no mask needed).

Here's a better description:
http://www.nondot.org/~sabre/graphpro/sprite4.html

This is an old technique that I remember from the MS-DOS days, but I recently ran across this again while programming the Philips CD-I.

I think the total advantage of compiled sprites is very low because the 68000 has very good working address registers. You win 4-12 clock cycles in no need to load an address register but you might loose it in the logic needed to select the right sprite drawing routine. Most advantage might be in an (unrolled) loop drawing lots of the same small sprites (like bullets) at different locations. But if the compiled sprite has to be selected loading a address register with the location of the sprite data is just as fast.

I have used code like that in my circle scroller and the earth demo but never for sprites.

Hans Wessels

cdoty
Retro freak
Retro freak
Posts: 11
Joined: Sat Feb 19, 2005 12:59 am
Location: Houston, TX
Contact:

Postby cdoty » Thu Aug 30, 2007 3:09 pm

Nyh wrote:I think the total advantage of compiled sprites is very low because the 68000 has very good working address registers. You win 4-12 clock cycles in no need to load an address register but you might loose it in the logic needed to select the right sprite drawing routine. Most advantage might be in an (unrolled) loop drawing lots of the same small sprites (like bullets) at different locations. But if the compiled sprite has to be selected loading a address register with the location of the sprite data is just as fast.

I have used code like that in my circle scroller and the earth demo but never for sprites.


That makes sense. The biggest advantage would be skipping a byte aligned transparent area, which doesn't occur very often in normal sprite data.

User avatar
prog99
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 118
Joined: Thu Jun 19, 2003 8:08 pm
Location: Edinburgh
Contact:

Postby prog99 » Fri Aug 31, 2007 6:32 pm

My centipede clone http://www.atari.st/view.php?id=276 uses them.

From memory (it was 15 years ago!)
If a line is 100% solid pixels then no mask required.
If a line is in less than 4 bit planes then you can make some small optimisations.
Line one colour then I think that was a speedup?

Disadvantages were -
No clipping
Memory consumed although I never compared this to a generic sprite route and preshifted sprites.
And I guess in a modern processor it wouldn't be very cache efficient?

Other examples from the demo/intro world are the big sprite in total apathy (you'll notice theres no transparent pixels in the bulk of it.) and some of the older dbug intros.
All my real skills are undervalued


Social Media

     

Return to “C / PASCAL etc.”

Who is online

Users browsing this forum: No registered users and 1 guest