Looking for Sound/Graphics C/C++ libraries

[master]

I`m coming from a PC environment where I`ve been creating games for last 7 years. During this period I`ve created/gathered/paid for lots of 2D/3D art assets and have created extensive code base in my own engine, including playable demos of at least 5 different genres. Obviously, that gameplay code can be easily reused on any platform, Atari ST nothwithstanding.

As a long-time fan of Atari I want to create some game also on this system, preferably on Atari ST. It should be a relatively fast process, considering my experience in games programming and low-level optimization on assembly level (especially mode 13h from the ancient times and assembler experience on Atari 800 XL where I coded complete Assembler IDE - Editor/Compiler/Monitor).

Since I definitely don`t want to reinvent the wheel and spend another year coding just some sound library in ASM (instead of just using something already written), I`d prefer using either some public sound library or if someone is willing to contribute his code, even better.

The same goes for gfx library, I imagine, I won`t be able to do real-time hi-poly 3D, as I`m used to on PC, but art assets can be rendered into sprites(with obvious palletization), therefore any sprite library would be great as a learning point.

Input should be easy to handle and gameplay, as I already said, is easy too.

Any pointers on C++ compiler for Atari ST ? Or is there some way of coding directly under Visual C++ 6 and just using some external compiler for Atari ST ? As for real-world development - that would be the last step when the game would work under emulator.

Thanks for any ideas/suggestions

[lp]

http://www.reservoir-gods.com/source.htm

[charles]

hi fine person

yes any thing would be quicker than starting at the bottom of the atari programming pole.

trust me there are only a few people who actually help out atari programmers and lonny is one of them!!!!
(nope ,i still like the feel of pascal lonney)

well any how i have two suggestions:

#1 is read up on gem , learn the atari programmable attributes
its operating system and disk system..the tos-== , the aes and the vdi , the bios ,,all found by googling

#2 is high tail it through mark williams c for the atari st or c-manship which is on line !

both of these examples have placed importance on identifying commands
which make programming easier to understand and how a user interacts with the atari.


charles
i really wish you luck , now here i go back to the pascal ,
bye!

[simonsunnyboy]

There is no C++ compiler for TOS but Pure C is an ANSI C package complete with IDE and all tools needed. For Development on Atari ST this might be a good start. I wouldn't recommend any other compilers as they are K&R C only.
Under Mint and if you are interested in crosscompiling, gcc is available too.

[master]

lp : Great resources ! Just what I was looking for to start somewhere without reinventing the wheel for 37th time. Thanks !

charles: Why on earth wouldn`t be people helpful here on these forums ? I mean, anyone who is into Atari, must be over 30 yrs. There aren`t any kids around this scene by now, except maybe kids of Atari fans.
But, you surely know better than me, who just joined these forums, so I`ll see.

Pascal ! Those were the days ! It was my most beloved language in which I programmed for over 10 years - starting on IBM PC XT at ~8 MHz 17 yrs ago through 386, until infamous Pentium error : Runtime Error 200.
But, I wouldn`t go back now that I learnt C++

simon : I sort-of assumed that there wouldn`t be a C++ compiler but hoped for at least partial implementation. At least C with classes would be better than pure C, but Pure C is way better than anything else.

In the meantime, if someone wants to leave some feedback (really, any feedback is welcome), here are some early screens from the action RPG game I want to make: They`re all in 16 colors,though not yet in exact Atari pallette.

[belboz]

There is no C++ compiler for TOS but Pure C is an ANSI C package complete with IDE and all tools needed. For Development on Atari ST this might be a good start. I wouldn't recommend any other compilers as they are K&R C only.
Under Mint and if you are interested in crosscompiling, gcc is available too.

I think the Lattice C compiler (version 5.6) is pretty much ANSI compliant also.

[giachi11]

If you want to use c++, you may try to cross compile with this:
http://vincent.riviere.free.fr/soft/m68k-atari-mint/
It's built for cygwin, and works fine for me.

[master]

A real C++ with exceptions, templates and STL on Atatri ST ?
That`s just fantastic !

It seems it`s a recent effort - the page mentions this year, so I probably couldn`t choose a better timing for creation of Atari ST games

Now I just need to install it all and get it into usable state.

[giachi11]

remember to add my name to the credits of your first game as adviser

[master]

Credits-listing is much cheaper than consulting services, so don`t worry

The final list will be probably huge, starting with RG team providing their codebase, through people here, to me. I`m going to have lots of questions, since this platform is new to me. Google to the rescue !

But first, I need to find the time to install the environment and emulator. Hopefully that`s a task achievable in one evening.



BTW, what is the performance of Atari 1040ST in terms of "fillrate" ? How many decently-sized transparent sprites (20x50) is it able to "animate" while maintaining at least 50 fps ? Rough estimate is enough. I`ll be using at least 8 palettes per screen.
I`m just curious, how many animation frames can my characters have per each animation (leaving memory issues aside, for now).

[simonsunnyboy]

I somehow get the feeling that you absolutely underestimate the power of a humble ST.
I cannot give exact technical values but I suggest to simply play some games to get a feeling what is possible. Keep in mind that a lot of cheating is needed!

The socalled sprite records cheat a lot to draw approx 200 balls with 16x14 pixels in 4 colors on predefined patterns. Search for "sprite record".
Those programs have no cpu time left for anything than moving the thngs along their predefined path.

[master]

Your feeling is correct. I`m just judging the performance from the games I`ve seen so far, and I haven`t seen anything spectacular yet, most games even don`t use the easy trick of using different palettes per each scanline. That was possible already on Atari 800, and i remember I did it myself too.

Those balls - I remember watching that video on YouTube, but somehow I have this connected to that "gfx card upgrade", or whatever is that add-on card HW called. Or was that the regular un-modded ST ?

BTW, I wouldn`t mind using all of the CPU power, since the game would be most probably turn-based, thus I need just a little bit of performance for Interface/Input. The rest can be used for rendering.


And what game, would you say, has the most advanced gfx ? I`ll google the screenshots, just tell me the name.

[bullis1]

A lot of people will say that "Enchanted Land" has the best graphics. Well, not really. The coding is very good, and there are a lot of colours onscreen, but the artwork is crappy and the sprites are pretty small.

"Ghost Battle" is the exact opposite. Amazing artwork, but technically speaking it's not that great. This is really a topic for a new thread.

Anyway, you can't use a different pallette for each scanline on an ST I'm pretty sure. There are different tricks you can use though. In fact, you can update the screen 3 times in one refresh (I think that's how it works?) and display 512 colours at once. Look up "Spectrum 512" for more info.

For best speed, all graphics that will be on screen at the same time should share one common 16 colour pallette, not individual ones. If you're a good coder, 32 colours will be doable.

Also, most of the graphic trickery you can do on an ST pretty much requires that you use assembly, as C won't be fast enough for alot of "high-colour" tricks if your whole game is C code, with no assembly for graphic routines.

I'm probably wrong about a few things I've said, but I assure you that you have a daunting task ahead of you! That said, I'm dying to see you make this game! I hope it works out...

[simonsunnyboy]

Screenshots don't help, they are still images. You need to see the movement to judge it.

Palette splits do cost a lot of CPU if you do them for every scanline.

[master]

A lot of people will say that "Enchanted Land" has the best graphics. Well, not really. The coding is very good, and there are a lot of colours onscreen, but the artwork is crappy and the sprites are pretty small.
"Ghost Battle" is the exact opposite. Amazing artwork, but technically speaking it's not that great.

First page on google didn`t reveal any actual screens, so I`ll have to leave it for later.

This is really a topic for a new thread.

There`s barely any activity as it is, so splitting this thread wouldn `t help it. A little OT won`t hurt.

Anyway, you can't use a different pallette for each scanline on an ST I'm pretty sure.

Well, I wouldn`t use 200 palettes, of course. Early estimates are in the range of 10-14.

In fact, you can update the screen 3 times in one refresh (I think that's how it works?) and display 512 colours at once. Look up "Spectrum 512" for more info.

Yeah, I`ve got this (alog with few others) in my bookmarks already from last month`s googling for Atari ST gfx programming.

For best speed, all graphics that will be on screen at the same time should share one common 16 colour pallette, not individual ones. If you're a good coder, 32 colours will be doable.

Not sure if I understand you correctly - you mean 32 colors per one scanline or per screen refresh ?

Also, most of the graphic trickery you can do on an ST pretty much requires that you use assembly, as C won't be fast enough for alot of "high-colour" tricks if your whole game is C code, with no assembly for graphic routines.

Well, I am prepared for assembly coding of gfx routines (but only gfx - the rest will be in C/C++).
In fact I`ve got experience with ASM routines for PC gfx mode 13h (320x200) where I spent lots of time on optimizing sprite routines so that they consume as little CPU time as possible.
That involved calculating cycles of each instruction and rewriting the code as many times as necessary until I was happy with the result.
Sure, that was on 80286, but from what I remember, 68000 had much cleaner ASM. So, provided I devote enough time to it, this isn`t an issue.

BTW, how similar is 68000`s instruction set to that of 6502 ? Though, I haven`t programmed in 6502 ASM for over 18 yrs, so I`ll hardly remember anything by now anyway.

I'm probably wrong about a few things I've said, but I assure you that you have a daunting task ahead of you! That said, I'm dying to see you make this game! I hope it works out...

Great ! Seems I have a first fan here who would actually like to see some new game on Atari ST!
It all depends on amount of free time I am able to devote to it, of course.


simon: I`ll check the game when I install Steem.

[unseenmenace]

BTW, how similar is 68000`s instruction set to that of 6502 ? Though, I haven`t programmed in 6502 ASM for over 18 yrs, so I`ll hardly remember anything by now anyway.

From what I've seen its certainly more like 6502 than 80X86 at any rate.

As for colours on an ST game you really should stick with just 16 colours for the main graphics I would think. You can still use palette splits for status panels and graduated raster skies to make things a bit more colourful. With a bit of careful planning you can use partial palette splits to allow different colours for certain parts of the scenery as in the underwater sections of Turrican II.

Spectrum 512 changes the whole palette 3 times every scanline for a maximum theoretical 48 colours per scanline from 512 (or 4096 on an STE) but this kind of trickery eats all your CPU time and makes designing the graphics a complete pig.

[daeghnao]

BTW, what is the performance of Atari 1040ST in terms of "fillrate" ? How many decently-sized transparent sprites (20x50) is it able to "animate" while maintaining at least 50 fps ? Rough estimate is enough. I`ll be using at least 8 palettes per screen.

We tend to measure sprite width in multiples of 16, because of how the ST's video memory is arranged. Most games seem to use a preshifting technique to speed up sprite drawing at the expense of memory. You need to store separate masks for each shift too, unless you're working some crazy bitplane magic.

I like the idea of "at least" 50fps The ST's video output is 50Hz or 60Hz in colour, and 70Hz in mono. You won't exceed 60Hz for a colour game, and that is achieved by very few games. The game with the most large sprites flying around at once that I've experience of is Lethal Xcess, but that doesn't have an awful lot of sprite animation.

As for "at least 8 palettes", you'll have to be much more specific about what you want to achieve. The ST's graphics chip uses a single 16-entry palette to look up colour values to generate the video output, and any technique for having more than 16 colours on screen involves changing the palette entries at the exact moment where the video chip is processing the line where you want a different colour. The maximum that anyone's managed is three complete palette changes per line on the screen, but that doesn't leave any processing time during the screen draw (the processor is literally rewriting the palette the whole time). Any processing has to be done during the VBL. You can see this in Spectrum 512; if you do any complex graphics operation (e.g. flood fill) it suspends the palette changes while drawing.

I`m just curious, how many animation frames can my characters have per each animation (leaving memory issues aside, for now).

The more pre-shifting you do, the less animation you'll have, unless you combine the two and have certain frames for certain offsets. Prince of Persia is an example of a game with a lot of animation frames.

In the end, I suspect you'll have to benchmark this yourself to get the right trade-off for the effect that you want to achieve.

[Nyh]

BTW, what is the performance of Atari 1040ST in terms of "fillrate" ? How many decently-sized transparent sprites (20x50) is it able to "animate" while maintaining at least 50 fps ? Rough estimate is enough. I`ll be using at least 8 palettes per screen.
I`m just curious, how many animation frames can my characters have per each animation (leaving memory issues aside, for now).

Nice question, it all depends on the quality of your sprite routines. If got very decent sprite routines with preshifted data, you can do 44 different masked 16x16 sprites with 16 colours.

This estimate assumes for every line: 4 move.l mem->reg (screen data), 4 or.l mem->reg (mask data), 4 and.l mem->reg (sprite data), 4 move.l reg-> mem (write screendata), in total 224 clockcycles per line. For every 16 pixels extra sprite width you have to add 112 clockcyles per line extra.

A single 16x16 preshifted sprite uses 4 kB memory for the sprite data and 2 kB memory for the mask data.

Note there is no time alloted for restoring the background, building the playfield or clearing the screen...

Hans Wessels[/code]

[master]

You can still use palette splits for status panels and graduated raster skies to make things a bit more colourful.

This is exactly what I`m planning to do, I just need 2 palettes for skybox, 2-3 for bottom HUD, at least 2 for top walls of the environment and 1 for the gameplay floor with enemies.

We tend to measure sprite width in multiples of 16, because of how the ST's video memory is arranged. Most games seem to use a preshifting technique to speed up sprite drawing at the expense of memory. You need to store separate masks for each shift too, unless you're working some crazy bitplane magic.

That is going to eat up the memory very quickly, I guess.

I like the idea of "at least" 50fps

You know - I`m spoiled by PC environment, where it`s normal if games run just 20-30 fps. Latest crop of gfx cards (GF6600 and above) runs my 3D games in framerate of about 200-400, so it`s been long time since I was constrained so much, but I appreciate the challenge.

The maximum that anyone's managed is three complete palette changes per line on the screen, but that doesn't leave any processing time during the screen draw (the processor is literally rewriting the palette the whole time). Any processing has to be done during the VBL. You can see this in Spectrum 512; if you do any complex graphics operation (e.g. flood fill) it suspends the palette changes while drawing.

I thought only 2 palette switches per scanline are possible. So, it`s great, if it was possible to have 2 characters side-by-side, each with different palette, plus third palette for their background.
But that`s probably impossible with animated sprites, performance-wise, right ? Or has anyone actually made something dynamic like that ?

In the end, I suspect you'll have to benchmark this yourself to get the right trade-off for the effect that you want to achieve.

Of course, I was interested in ballpark figures, as Nyh pointed out in next post.

[daeghnao]

The maximum that anyone's managed is three complete palette changes per line on the screen, but that doesn't leave any processing time during the screen draw (the processor is literally rewriting the palette the whole time). Any processing has to be done during the VBL. You can see this in Spectrum 512; if you do any complex graphics operation (e.g. flood fill) it suspends the palette changes while drawing.

I thought only 2 palette switches per scanline are possible. So, it`s great, if it was possible to have 2 characters side-by-side, each with different palette, plus third palette for their background.

Each change to each individual colour takes a certain amount of time, so while you can do three palette's worth of changes (probably 45 colours in all, if you want a consistent background colour) on a line they don't all happen at the same point horizontally. You need to think this through carefully - you say "plus third palette for their background" but it really doesn't work that way. There's only one palette, you just change it one colour at a time and that changes how that particular four-bit pixel value gets rendered on the screen at whatever point the shifter chip happens to be generating its output. If you really wanted entirely different palettes side by side, you'd have to have them in the first and last 100 pixels of the screen and be very careful about which palette entries you use inbetween.

But that`s probably impossible with animated sprites, performance-wise, right ? Or has anyone actually made something dynamic like that ?

It's certainly possible, but it's challenging. If I were approaching this idea of yours, I'd get the sprite rendering sorted first, then worry about palettes, then trade that off against sound and animation. In the end it's a matter of slicing up the processing-time pie and the memory pie (and in some cases the disk-access pie and the disk storage pie) to get the best effect you can.

[MiggyMog]

I have seen a good few games which spilt palletes For control/score panels & use rasters for sky gradients, some of these combine the palette switch with a 50/60hz switch to open the borders to extend the screen by a few lines (Chambers of shaolin,Pang,Wings of Death,Lethal Excess,Obsession {More?})

Raster skies which change only one colour per scan line are used in quite a few games, Turrican,Venus Flytrap,Chronicles of omega,Enchanted land)

If you are only changing one colour you can do 'Plasma' effects and I think the colour changes every four pixels? (Nasty CPU usage)

The STE only game Obsession set the benchmark it has I think the most messing of the colour palettes duiring in game play, it also adds an extra 16 pixels to the left border by using an STE only border trick,removes the bottom border & plays a 4 Channel Mod and 1 channel sound!

There is the other method of 1 switch per VBL of the palette/image but the colours have to be close to avoid making you sick due to the refresh rate, this has been used in conjunction with alternate chequeboard dithering over the two frames to reduce the harshness.

[Nyh]

The maximum that anyone's managed is three complete palette changes per line on the screen, but that doesn't leave any processing time during the screen draw (the processor is literally rewriting the palette the whole time). Any processing has to be done during the VBL. You can see this in Spectrum 512; if you do any complex graphics operation (e.g. flood fill) it suspends the palette changes while drawing.

I thought only 2 palette switches per scanline are possible. So, it`s great, if it was possible to have 2 characters side-by-side, each with different palette, plus third palette for their background.
But that`s probably impossible with animated sprites, performance-wise, right ? Or has anyone actually made something dynamic like that ?

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.

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. (Maybe even more if you open borders because then you have more pixels on a scanline but also extra processor time needed for opening the borders so I am not 100% sure whether you can get more colors on a overscan scanline.)

Hans Wessels

[master]

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.
That`s just another reason to go for turn-based gameplay where the smaller performance won`t suck that much.

This estimate assumes for every line: 4 move.l mem->reg (screen data), 4 or.l mem->reg (mask data), 4 and.l mem->reg (sprite data), 4 move.l reg-> mem (write screendata), in total 224 clockcycles per line. For every 16 pixels extra sprite width you have to add 112 clockcyles per line extra.

Thanks for sharing your benchmark data. It`s probably going to take some time till I reach this level of performance, but at least I have some actual numbers that I have to reach.

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.
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 ?

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.

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.
Any ideas, besides lowering the size of sprites ?

[master]

Each change to each individual colour takes a certain amount of time, so while you can do three palette's worth of changes (probably 45 colours in all, if you want a consistent background colour) on a line they don't all happen at the same point horizontally. You need to think this through carefully - you say "plus third palette for their background" but it really doesn't work that way. There's only one palette

Yes, I understand it that each batch of pixels in current row is tied to current palette, I just wasn`t very specific/correct. I was merely speculating about having separate palette for the background static sprites between the characters, but that would obviously limit the distance they could get to each other, not even talking about overlapping with given area that would have to change the colors when the other character would approach it. So it was a stupid idea from the start, except such type of game, where opponents stay at the left and right part of screen and can`t overlap, so it`s purely hypothetical.

It's certainly possible, but it's challenging. If I were approaching this idea of yours, I'd get the sprite rendering sorted first, then worry about palettes

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.

then trade that off against sound and animation. In the end it's a matter of slicing up the processing-time pie and the memory pie (and in some cases the disk-access pie and the disk storage pie) to get the best effect you can.

Never-ending trade-off cycle. You see ? I completely forgot the music ! How much can I expect it to take from my performance ?

[master]

The STE only game Obsession set the benchmark it has I think the most messing of the colour palettes duiring in game play, it also adds an extra 16 pixels to the left border by using an STE only border trick,removes the bottom border & plays a 4 Channel Mod and 1 channel sound!

Definitely ! I just checked the screenshots and they look fabulous ! Other games mentioned are nice too, namely Ghost Battle.

There is the other method of 1 switch per VBL of the palette/image but the colours have to be close to avoid making you sick due to the refresh rate, this has been used in conjunction with alternate chequeboard dithering over the two frames to reduce the harshness.

Haven`t heard of it. Care to elaborate a bit more ?