Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team
simonsunnyboy wrote: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.
First page on google didn`t reveal any actual screens, so I`ll have to leave it for later.bullis1 wrote: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.
There`s barely any activity as it is, so splitting this thread wouldn `t help it. A little OT won`t hurt.bullis1 wrote:This is really a topic for a new thread.
Well, I wouldn`t use 200 palettes, of course. Early estimates are in the range of 10-14.bullis1 wrote:Anyway, you can't use a different pallette for each scanline on an ST I'm pretty sure.
Yeah, I`ve got this (alog with few others) in my bookmarks already from last month`s googling for Atari ST gfx programming.bullis1 wrote: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.
Not sure if I understand you correctly - you mean 32 colors per one scanline or per screen refresh ?bullis1 wrote: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.
Well, I am prepared for assembly coding of gfx routines (but only gfx - the rest will be in C/C++).bullis1 wrote: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.
Greatbullis1 wrote: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...
master wrote: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.
master wrote: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.
master wrote:I`m just curious, how many animation frames can my characters have per each animation (leaving memory issues aside, for now).
master wrote: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).
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.unseenmenace wrote:You can still use palette splits for status panels and graduated raster skies to make things a bit more colourful.
That is going to eat up the memory very quickly, I guess.daeghnao wrote: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.
You knowdaeghnao wrote:I like the idea of "at least" 50fps![]()
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.daeghnao wrote: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.
Of course, I was interested in ballpark figures, as Nyh pointed out in next post.daeghnao wrote: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.
master wrote:daeghnao wrote: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.
master wrote:But that`s probably impossible with animated sprites, performance-wise, right ? Or has anyone actually made something dynamic like that ?
master wrote: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.daeghnao wrote: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.
But that`s probably impossible with animated sprites, performance-wise, right ? Or has anyone actually made something dynamic like that ?
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.Nyh wrote:If got very decent sprite routines with preshifted data, you can do 44 different masked 16x16 sprites with 16 colours.
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.Nyh wrote: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.
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.Nyh wrote:A single 16x16 preshifted sprite uses 4 kB memory for the sprite data and 2 kB memory for the mask data.
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.Nyh wrote:Note there is no time alloted for restoring the background, building the playfield or clearing the screen...
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.daeghnao wrote: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
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.daeghnao wrote: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
Never-ending trade-off cycle. You see ? I completely forgot the music ! How much can I expect it to take from my performance ?daeghnao wrote: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.
Definitely ! I just checked the screenshots and they look fabulous ! Other games mentioned are nice too, namely Ghost Battle.MiggyMog wrote: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!
Haven`t heard of it. Care to elaborate a bit moreMiggyMog wrote: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.
Users browsing this forum: No registered users and 3 guests