stardot.org.uk

Hey,

Just reminiscing on my foray into Archimedes programming back in the day, and how I was never able to get the performance I needed in MODE 13. I thought I'd re-explore some techniques for getting sprites on the screen and see how they could be improved.

I was always targetting lowest common denominator specs (i.e. 8MHz ARM2) so this pretty much meant unrolling loops as much as possible and writing multiple different routines.

I started work at one point on a game similar in style to Tom Cooper's Hamsters, but I wanted lots of parallax layers and 50fps update. Wasn't ever going to happen! But I wonder if it were possible and whether I was doing it wrong.

Here is a spreadsheet containing three different sprite routines for comparison, with some rough timings. Each of them aims to plot a 32 pixel wide sprite row in MODE 13, unclipped, and offset one pixel to the right of a word boundary.

The first tries to do multiple loads/stores, and builds a sprite mask from the data (using colour 0 as the transparent colour), thus halving the amount of sprite data required.

The second is the method used by Tom Cooper's games (from what I remember), multiple loading but then conditionally STRBing pixels if they are non-transparent. I remembered this being quite good, but looking at the timings, it doesn't really perform as well as the other two, unless the sprites are mostly transparent (this routine performs better the more transparent the sprite - you can change the percentage of transparent pixels in the spreadsheet).

The third relies on a sprite mask being interleaved with the data, every 16 pixels. This performs the best, at the expense of doubling the sprite size. Maybe in MODE 13 with its bigger memory requirements, this couldn't have been an option.

But what other methods are there to improve on this? As ever, it's the memory vs speed trade-off.

Interested to know how other people constructed sprite routines on the Arc!

Just added a fourth: a basic unmasked 32 pixel wide sprite, but being stored to an unaligned screen address. It's the shifting which creates the overhead... it looks like the only way around that is to store 4 different versions of the sprite, but that's soon going to add up...

I guess the next step is to eliminate the shifting by creating shifted versions at runtime (but only the sprites you actually use). That immediately rules it out as a 1Mb title though (thus eliminating one of the lowest common denominators, unexpanded A3000s).

Let me complete writing this :
viewtopic.php?f=29&t=10443
where most of the ideas for my sprites plotting routines are and then I'll come back to tell you the choice I made (none of the ones you listed : they are too slow).

I'll make everything freely available btw, exactly like for these filling routines, once complete (ie really fully optimised).
And don't worry IIRC all the routines take less than 260 kbytes since they can cope with sprites whose one continuous horizontal segment could reach up to 384 pixels long, and I don't think anybody would ever need that.
It's not that I don't want to explain now but in English it's going to be difficult.
I had started at Wakefield, with no notes, and made some mistakes but most of the ideas are in the video on Youtube.
See the thread about Zarch with Jonathan too, lots of ideas expressed there.
The 'Amiga lettuce plotting algo' is in my head and works a treat on paper but not yet coded.

I'm interested in examples which would apply to an actual game though, rather than the sort of thing you're doing in your demo with enormous sprites, which are more a one-off kind of thing (although it would potentially be applicable to something like an end-of-level boss).

One of the prototypes I played about with was something a bit like Sonic the Hedgehog or Mario - an 8 way scrolling platformer with multiple parallax layers. Typically a foreground scenery tile is going to be about 32x32 - then the background layers would maybe be more repeating motifs. On top of this were going to be lots of moving things of varying sizes (from 24x48 down to 16x16).

So the idea would be to find the best way to plot 50% of the screen with 32x32 tiles, while the other 50% consisted of background layers moving at a different speed. Then on top of this would be moving sprites and finally foreground scenery. It seems to me that maintaining 4 copies of all these sprites at their various alignments seems more and more necessary, but even then perfoming the load/mask/or/store operation is also reasonably slow. Either way it seems like a memory hog.

And we haven't even spoken about clipping them off the edge...

I was doing this kind of thing in Blurp (although it was a bit of a different design) - in the end I could plot three layers, plus loads of movement, explosions etc, all at 50fps - but I had to use MODE 9...

Please bear in mind, I never had an Arc and only read the ARM docs in the 80s!
If you were doing a game with cartoon style gfx, could you use 8bpp with 4 colour background (maybe hardware scrolled), 3 colour mid ground (+1 transparent), possibly with some colours being translucent and 15 colour foreground (+1 transparent), again, some could be translucent.
You would then only load/store the background (possibly, store many if repeated pattern) and load/or/store the rest.
The parallax would go against my preference for making games out of things that a platform does best, but others may decide on a game's look and feel and then make it for a platform.
e.g. When we could only really do plastic looking 3D (basic diffuse+specular lighting), I used to say, instead of trying to make things photorealistic, can't we make a game about plastic people in a plastic world.

tricky wrote:If you were doing a game with cartoon style gfx, could you use 8bpp with 4 colour background (maybe hardware scrolled), 3 colour mid ground (+1 transparent), possibly with some colours being translucent and 15 colour foreground (+1 transparent), again, some could be translucent.

Unfortunately you don't have a fully redefinable palette in 8bpp mode, so the available colour choices in this scheme would be largely fixed, and quite bad.

Oh, sorry, did I mention it was only the assembler bits I read

So kinda like bitplanes? Problem is the rubbish palette in 8bpp modes - you can only change the meaning of the bottom 4 bits, and the top ones are hardcoded, so you'd most likely end up with some pretty wacky colours!

The parallax was not an essential thing by any means, but it was just because it was in vogue at the time (Amiga and all that...) and I felt sure the Archimedes could probably do it... but I never had any luck with 256 colour modes, hence this thread!

I totally agree by the way about designing your game around the hardware - I used to be the same with 3D games. My pet hate was cutscenes that could have been more realistically portrayed by Thunderbirds puppets!

Edit: like wot Tom just said.

Incidentally on Bomber Blaster I used something very similar to routine #2. I never really attempted to optimise it much though - it seemed fast enough for that game.

So maybe the trick is to consider each word of sprite data as

• fully transparent (store nothing)
• needs a custom mask
• fully solid (can be directly stored)

Stuff that into a descriptor word which designates the configuration of sprite data per row (2 bits per sprite data word per row). Then, implement a different routine for plotting each type of sprite row, one per alignment. It's still going to be pretty slow, but at least you'd save time on masking when you didn't need to (e.g. the continuous solid part inside a sprite). But maybe that's just too complicated. And would require 3^(max width/4) routines! Maybe not then

And then you'd have to throw it all away on ARM3 anyway (I have the impression that this kind of code actually runs slower on ARM3 than on ARM2, due to the syncing of the memory and CPU clocks stalling the CPU for longer).

For a very sparse sprite (i.e. one with mostly transparent pixels), you could 'compile' the sprite into a series of MOV and STRB instructions, thus eliminating LDRs or LDMs, and avoiding loading transparent pixels that are never plotted anyway. You would lump all the sprite pixels of the same colour together in a block of STRBs, with a single MOV instruction for each colour. So, if there are 65 different colours used in the sprite, there would be 65 MOV instructions. The method is rather limited in that it really only works (easily) for small-ish sprites because of the max. allowed size of the offset specified in the STR instruction (+/- 4096, IIRC ?). It also doesn't lend itself to clipping, so if the sprite is also to move out of the screen/frame buffer, a separate plotter would have to handle that case.

Is it efficient? I think it can be, especially on an ARM2. But how about on an ARM3? I really don't know...

Ok, I'm not naming it (to avoid unpleasant memories and some personal embarrassment ), but I actually had a totally naff game published (!) which I'm pretty sure employed the method I described above. (And for which I received a cheque for a whopping £14.10, plus two games in exchange.) The sprite in question was a ring, and that meant lots of transparent pixels. So, yeah, the MOV/STRB method actually got used in a 'real-world' situation.

Did anyone else 'compile' sprites in this manner?


EDIT: I deleted my off-topic rant regarding performance of OS_SpriteOp on the Raspberry Pi 2


David.
--

http://www.proggies.uk

David1664 wrote:For a very sparse sprite (i.e. one with mostly transparent pixels), you could 'compile' the sprite into a series of MOV and STRB instructions, thus eliminating LDRs or LDMs, and avoiding loading transparent pixels that are never plotted anyway. You would lump all the sprite pixels of the same colour together in a block of STRBs, with a single MOV instruction for each colour. So, if there are 65 different colours used in the sprite, there would be 65 MOV instructions. The method is rather limited in that it really only works (easily) for small-ish sprites because of the max. allowed size of the offset specified in the STR instruction (+/- 4096, IIRC ?). It also doesn't lend itself to clipping, so if the sprite is also to move out of the screen/frame buffer, a separate plotter would have to handle that case.

Is it efficient? I think it can be, especially on an ARM2. But how about on an ARM3? I really don't know...

Ok, I'm not naming it (to avoid unpleasant memories and some personal embarrassment ), but I actually had a totally naff game published (!) which I'm pretty sure employed the method I described above. (And for which I received a cheque for a whopping £14.10, plus two games in exchange.) The sprite in question was a ring, and that meant lots of transparent pixels. So, yeah, the MOV/STRB method actually got used in a 'real-world' situation.

Did anyone else 'compile' sprites in this manner?


EDIT: I deleted my off-topic rant regarding performance of OS_SpriteOp on the Raspberry Pi 2


David.
--

http://www.proggies.uk

Very good idea !
Bubble Fair used this technique to plot the bubbles.
The pity is that Laurent didn't write a code generator to generate the opcodes, but he handcoded the sequence of ARM instructions to plot the sprites.

In my awful with a glitch preview of a demo of 1992 I had written a code generator, unfortunately I didn't know as much as I know now so the code is quite poor (still 3 big sprites and 50 fps. Now it would be 5. And yes with a bit of lettuce but no dressing sorry).

Guess what : the technique you describe can marginally be improved.
One way is if your sprite (or a previously plotted sprite in the sequence of sprites you know you'll have to plot anyway) has at least 1 STR or STM to plot it you could very well not need a MOV,#colour because this colour happens to already be in the lower 8 bits of one of your previously 'loaded' registers ... or lower 8 bits from any register after all

And yes the offset is +/- 4096 EDIT : 4095 (1 bit to tell the sign and 12 bits to encode the value).

I explored the possibility of generating routines tailored to specific sprites a long time ago, not exactly the approach you describe David, but essentially a way of removing the redundancy from sprites with lots of transparent areas. But I found it wasn't particularly scalable for a game with a large number of sprites, particularly after generating versions for each screen address offset, and versions which could be clipped.

Zarchos, you're a big advocate of pre-generating code (or do you do it at runtime?) - my question is, how well do you think your ideas scale to a game with, for example, 128 32x32 sprites forming the scenery and backgrounds, plus 100 sprites ranging from 16x16 to 32x48 representing moving characters with plenty of transparency? This I'd consider to be a very conservative estimate of the sort of sprite resources used by a typical game (there could easily be more scenery graphics in fact).

You say that none of the routines I posted are really fast enough, and I'd probably agree that they don't quite meet the performance requirements for a 50fps game in Mode 13, but how would you suggest improving them (for the exact case I described - a 32 pixel wide sprite with transparency, plotted at any screen address)?

It seems the requirement of plotting a sprite to an unaligned address is one of the biggest bottlenecks as essentially there are only two options:

• Store 4 copies of the sprite at different alignments and watch your sprite memory budget get blown away
• Create 4 different routines which plot at different alignments, the unaligned versions being much slower than the aligned versions (and also the ones used 75% of the time!)

For scrolling games, when plotting background scenery, there's secret option number 3:

• Use the border position hack to shift the screen in two pixel increments, but then this still requires the ability to plot background sprites at a 1 pixel offset, if you want pixel-by-pixel movement

I guess you have to rely on multiple copies too, i.e. plotting the same data multiple times on the screen to create a number of identical enemies - which means you'd need everything to be at the same alignment. This could also be a good trick when plotting the background: to somehow keep track of multiple instances of the same scenery sprite and plot them altogether from a single sprite data load. Whether the housekeeping required for maintaining the positions of multiple copies would be worth the saving in rendering time would have to be tested.

So far we haven't thought about clipping at all. My solution for this would be to have an offscreen edge, hidden by the left or right border. Then you wouldn't need a special routine, you'd just plot the entire sprite and let it go over the visible edge into the offscreen piece. We're lucky that VIDC has the facility to define the border dimensions separately from the screen size like this.

@ Rich, as I said it is complex to set up everything in order to get tables of datas and pointers your game is going to use.
What I did, is what I tried to explain there :
https://youtu.be/CaXAzyWUllY?t=9m24s
Sorry for the bad English, Steve got me by surprise as I wanted him to explain what my routines do.

Remember also that there are 2 types of sprites you use in a game :
1/ - Sprites you need immediately (your ship, the weapons, the HUD) and then
2/ - Sprites you don't immediately need, but a table you read at a certain granularity tells you they'll have to be plotted in x frames (a big ship, some background elements etc ...)

For 1/ you're stuck with having everything in memory all the time (4 copies of the shifted data (words) inside them, 4 copies of the assembled generated code to plot them ; all this because of the 0 to 3 offsets from a word boundary with a 256 colour screen mode).
For 2/ Transparently while you're playing the game, with no slowdown, you'll call some routines to prepare the assembled generated codes to have these sprites ready to plot. (My routine use a granularity of one horizontal segment in a sprite to assemble the corresponding generated code to 'compile' it : so the CPU load is unnoticeable, per frame).

It also means the action in your game, or even the moving background elements in your game, can be delayed depending on the bandwith used by what you've got already to deal with on screen (imagine you're fighting against a big boss like in scorpius, and you know you've got only 10 scanlines left per frame with all the weapons etc : even if your table of events tell you you should now display another big boss, you'll delay it until the intial boss is destroyed, thus freeing some bandwith. Of course it means in the structure describing all your sprites you know their CPU load (the max of the 4 copies and the max of its animation if any), to be sure when you'll plot it it won't make the framerate drop from 50 fps to 25 !).

Of course you must have an efficient memory manager/cleaner to, transparently, per frame, free and rebuild continuous areas of free memory to be able to assemble the generated codes when it's going to be necessary.
All this can look pompeous but it's really not a difficult algorithm.

Listen to what I say at Wakefield : on the game disk there's no compiled sprites : the routines and the 'compiler' are inside the game and 'only' uses tables of infos and datas from the sprite, stored on disk. (these can be crunched by the way, no big deal and not a lot of CPU load to deal with that).
In 1992 my preview of a demo, bugged and ugly, loaded everything already compiled and it's lame (but this preview was just a proof of concept, and it's why I never released it at the time, and guess what even with the glich and the ugly graphics I reached my goal).

To answer your questions abour timing and memory usage I'll have to run some tests, but honestly I see no reason why it wouldn't work on a 2 Mbyte computer, in particular if there are some slow sequences in the game (or even a halt, like 'Warning' etc...) to do a disk access and get some datas.


I've got several solutions for the clipping but these haven't been tested yet and I must check the tests (to choose this routine or that routine) are worth doing versus doing more stuff than it seems necessary to perform, but ending up being faster.

Final note to people who didn't understand me : I had to entitely rewrite my routines because now they are compatable with RasterMan.
And it is not a 'small' advantage, trust me.
There's a ridiculously tiny cost in terms of speed, so it's worth it.
I don't agree with what you say about 100% software against hardware scrolling : sorry to tell you even in the worst case scenario hardware will win.
The impossible worst case scenario is that all sprites on screen (your ship, the enemies', weapons, moving background elements etc ...) are all gathered at the exact same location, so doing a redraw will cover the same area so it's a waste of CPU cycles, when only one full 100% software redraw would be smarter. Since this case is impossible, hardware will always win. Of course it'll win only your unplotting algo is very efficient (and have a look at Poink's lettuce, of course the redraw isn't the one you should do 'in theory' because of the timing formulaes of LDM and STM : you'll save some time apparently manipulating more words than visually needed. Yes : more redraw will actually be faster ! An LDM/STM sequence with some registers apparently not needed will prove faster than LDM/STM + ADD + LDM/STM to cover exactly the words you should visually redraw).

Of course, in a typical shmup, the enemy patterns and the timing thereof don't change due to the actions of the player; which means that other than a handful of things like aimed shots, the player position and player weapons, the game is predictable on a frame by frame basis, which is convenient if your shooter occurs within a finite, scrolling level especially if you want your beasties to crawl out of pipework.

Having the same thing happen consistently, is also important to maintain a consistent difficulty level across machines of varying performance. If a second boss is merely delayed by the lack of CPU time, rather than the first having been defeated, a player on an A3000 may only ever face a single boss at a time, whilst a player on an 33MHz A5000 ends up facing multiple simultaneous bosses.

Because the game is deterministic, you can calculate the exact frame where an enemy becomes visible (and from there work out when you would start needing to generate your blitting code) and the exact frame the last enemy of that type leaves the screen (when the memory can be reused). So long as your sprite generation is similarly deterministic - you also know how much memory the generation is going to use, so you can even precalculate where it's going to 'land' in memory. You don't even have to do any explicit deallocation or clean up, as the next occupant can be left to implicitly overwrite the previous.

This allows you to generate an events table which dictates that on frame 100, we start compiling sprite A into memory from &48323, at frame 200, 6 copies of sprite A start following path Z and so on. At runtime, all you've got to do is do proceed through the events table in order, calling the functions as you go. Bosses are handled fairly simply within this - there's simply a boss mode within which the frame counter used to walk the events table is paused until the boss is defeated.

The nice thing is that the precalculation can be performed easier to write, but less efficient code (eg., BASIC, Python etc.,) than you can expect to need for a runtime implementation. Even better, because you've got full knowledge of the memory usage, the ability to use a far more powerful machine and there's not a deadline 0.002 seconds away, you can better plan the usage of sprite memory to reduce fragmentation, and you can check whether a level design fits in memory, without having to load it up inside the game to see if it crashes.

You do have to leave an appropriate buffer to account for player actions (eg., they fire their weapon), but this applies whether you allocate resources at runtime or ahead of time.

Zarchos, thanks for the explanation, I'll take a listen to your Wakefield talk. So you're preparing routines at runtime - but are they somehow customized per sprite (depending on transparency), or just per size? Taking the example of a 32 pixel wide scenery tile with transparency, e.g. part of the top of a palm tree, what kind of code might you expect it to generate?

Have a look at the beginning of this video -
https://youtu.be/-yg7cQp3LWI?t=18s

Ignoring the third parallax layer and sticking with two - this is the kind of thing I was hoping to be able to recreate back then (and could have done so in Mode 9, but not in Mode 13 - not unlike Zool, I guess). This is also a demonstration of why I think hardware scrolling wouldn't be a viable solution in this case: there is not a dominant layer - both the background and foreground layers dominate on the screen at different moments of the gameplay, and also much of the background is animated. This is exactly the sort of thing which, if possible, would make it stand out enormously from Amiga games of the period - but would need almost entirely a software full screen update approach, with keeping track of screen spans to ensure that as little as possible was being overdrawn.

With your hardware scrolling approach, how do you restore the background? Are you storing it into a buffer prior to drawing sprites (assuming that sprites contain holes and so can't just get away with redrawing the edges)? Or are you calculating what needs to be restored and essentially plotting unmasked sprites over the top? When there is so much moving on screen, my instinct is that this approach can often result in having to draw as much as if you were just refreshing the screen completely - looking back at the Sonic example, assuming the foreground is erased and redrawn over the foreground, at times there's a lot to redraw there. Even if it were the other way round (background redrawn through the holes, as in Warlocks), sometimes there's a lot of background visible, plus it's animated.

But this is why I'm interested in seeing what kind of maximum fill rate is possible in a real game example - I still think ARM2 is probably not quite up to it, although an ARM3 could probably kick ass in this case.

Wow hey forget Sonic I agree there's far too much on screen : here you really need a console to achieve these results.
What I meant saying the hardware solution will be better is for a game like this one :
https://www.youtube.com/watch?v=bxN6eA3-eZg
it's perfect for the Archie (to me. I can be wrong but I honestly think it's doable in 256 colours on the Archie, 50 fps, or at least with 70% of what's on screen on the megadrive): in the 480 kbytes of screen memory IIRC, like in my 1992 demo, you plot 4 times (or 5, can't remember) the new parts of tiles to display, each distant of the size of 1 screen buffer, do your visual scrolling down with the MEMC video DMA register (its value decreases to get visual scroll down), and when you've reached pointing 32*1024*1024-480*1024 you reset your values to start again at 32*1024*1024-screen gameplay area*2.
With this method you've always got a whole buffer (at the end of the screen memory, address decreasing in memory at the pace of your visual/work on screen bank) of your background made of tiles : and your compiled 'unplotting-sprites' will read in this unaltered bank. (*)
Explanations simplified, of course.
The glitch Poink insisted on demonstrates a mistake in my 1992 preview of a demo where I don't reset the values of the video DMA to the initial values at the right frame, and I do the flip work on one bank/display the other although I haven't drawn the sprites (I did deleting the edge, but not plotting the sprites at their new positions for this new frame in the bank I show, but in the bank with reset values but the DMA video value doesn't point to it).

To explain better I'll have to find back my notes, but I know where they are. A drawing is better than my text.

For horizontal scrolling now there's RasterMan, I think there are some good, much faster solutions than the ones used at the time, since now you can decide to show a scanline of only p pixels when the layout of your screen memory is in fact an arrangement of continuous (p + nv bytes)
nv = non visible pixels, and a big value is now possible thanks to RasterMan and its ability to alter the MEMC video DMA address at the end of each scanline.

Sorry for the English, I wonder how you can understand all this.

Don't think I'm a retard dreaming the Archie is much better than it is.
I run some tests. I've got some figures from my routines. And I haven't told you about my generated code 'See through like through a window' routines yet. Nor did I about the timings of 1 load N store routines. And now there's RasterMan providing features unknown so far.
And guess what even the excellent , fastest on the Archie, QTM routines by Steve can be made faster. Read QTM docs : you'll learn about QTM turbo. Sorry Amiga fanboys : you'll have to forget this idea the Archie is slow at reading a module : the time needed can be halve in TWO. WOOOW !

=>There's a huge, never used so far reserve of power in this 32 bit Acorn machine, and amazing stuff, to me, is doable.

People always claiming the Amiga is great should remember it became great ONLY because some people tried to push it to its limits, used far fetched algos (see the use of the copper to fill round shapes, not accurately, but close enough to make it perfectly usable).
These people ready to desesperate on what the Archie can produce disappoint me : behind what's in a commie's guts, there's the madness of people who handcrafted devilish algos. Why wouldn't it be the case for the Archie ?
If I had not asked Steve to work on a pseudo H-Sync routine compatable with his QTM tracker (after I had watched and read the text of the cMEMC demo, and fell of my chair http://www.youtube.com/watch?v=nz-Jvvy7Qlo )
everybody here would still think the Archie can't do it.
Tssss... don't surrender that soon. Fight every admitted opinions (yes the majority is wrong : 1st rule) and think a dream can come true, start from scratch and find your own optimised solution.

Hats off to Steve, really. To me in the life of the Archie there is the 'before' and the 'after' RasterMan, truely.


(*) There is a solution to save screen memory. The buffer could very well be built in main memory, and not in the 480 kbytes of screen memory.
This way for a vertically scrolling shoot em up, IIRC instead of having a 384x240 screen mode, 384x288 is possible, even leaving some room in the max 480 kbytes the MEMC can address for the screen memory.

Zarchos wrote:The glitch Poink insisted on

Frankly, I'm rather fed up with your behaviour.

You're spending post after post abrasively bashing other Archie coders and lashing out at 'Amiga fanboys' but you apparently feel entitled to have a multi-day meltdown if someone so much as mentions a bug in your code. Given your evident keenness to dish out criticism, you should learn to take a little too.

And, for the record, you're the one who's been insisting "the glitch" remains a continuous topic of conversation. There was no need to bring it up in this thread, and certainly no need to use it as an opportunity to attack others.

Chucked this together in a week for someone a while back, it's the startings of a game engine but I've kind of had to drop it because of AMCS (amcs.3rdevent.net).

You're welcome to muck around with it, although the royalties for using the code are unreasonably steep, j/k (unless it's commercial use)

It's a pretty quick way of dealing with clipping and unaligned sprite handling.

qUE

poink wrote:

Zarchos wrote:The glitch Poink insisted on

Frankly, I'm rather fed up with your behaviour.

This will make my day. Thanks.
The sentence was perfectly adequate to illustrate what my algo does. (Or well : doesn't in that case).


For your other rumblings please bring some evidence, links etc ...
'abrasively bashing other Archie coders' ?
Where and when ?
You'd better read again the thread where there was a talk about BBC games vers Speccy games where you quoted me by error, this might had upset you but I'm not the culprit.

And for the Amiga : I've got no regrets at all when I read what you can write about the Archie. None.

Final note : you're off-topic, so stop moaning to manipulate people to get their compassion please, after I exposed your nonsense in the other post.

Good day !

Will people please start playing nicer. The bitterness is getting very tiresome

Paul

s1paulr wrote:Will people please start playing nicer. The bitterness is getting very tiresome

Paul

seconded.

One of the main reasons I come here is to read technical discussions on things like sprite plotting and hopefully contribute, but seeing people get upset really spoils them for me.

Off topic :
Thirded . This forum I've found to be one of the most welcoming on the internet. You can make mistakes and people nicely point them out. People really try had here to push the boundaries of what is possible with amazing results. There can be long discussions on what might be specialist topics but these aid the understanding. I really like the detail of some of the topics even though I will never use the information.

Zarchos wrote:For your other rumblings please bring some evidence, links etc ...
'abrasively bashing other Archie coders' ?
Where and when ?

You've done it whenever you've tried to explain the lack of certain showpiece games on the Archimedes. Your narrative requires that the Archimedes hardware is absolved of having any contribution, so you've simply made other Archie programmers the cause of the malady. You've even gone so far as to bemoan that if we'd only had the people the Amiga did, we'd have had "wonders".

The simple truth is, we did have talented programmers, who did produce wonders. Our wonders just weren't in the form of 2D shmups or platformers. The first most of us came across was probably !Lander on the RISC OS 2 Apps discs. Virus on the Amiga runs no where near as well as Zarch does on the Acorn.

And it's not a one off, there's Galactic Dan, Chopper Force, Saloon Cars, Stunt Racer 2000, Starfighter 3000 to name but a few. Similar games on the Amiga games just don't run as quickly or have no where near as much scenery. That's a theme which continues even to our port of Wolfenstein3D - it runs better on a stock A3010, than the Amiga port runs on an A1200 with the benefit of an accelerator card.

Even the Arc ports of Amiga games show the talent we did have. They're not perfect ports - but you generally need a side by side comparison to tell.

Zarchos wrote:And for the Amiga : I've got no regrets at all when I read what you can write about the Archie. None.

I love the Archie but I'm unwilling to overlook technical facts just because I'm fond of the machine. It's a workstation, unlike the Amiga, it wasn't intended as a games machine.

Stating that the Amiga's chipset gives people writing shmups and platformers a significant advantage over people writing similar games for the Arc is just the truth. Your claims to the contrary just do a lot of people and their work a disservice.

Zarchos wrote:Final note : you're off-topic, so stop moaning to manipulate people to get their compassion please, after I exposed your nonsense in the other post.

In the other thread, you didn't bother addressing my points, called me a liar, accused me of being a troll and repeated your usual screed about Amiga fanboys.

You've also apparently decided to escalate your bullying this morning - specifically by changing your avatar to a plant in order to have another petty jab. In doing so, you've made it crystal clear to all that your behaviour is intentionally abusive.

Poink, breath deep, people post stuff on the internet . I think Zarchos is just frustrated like I was a while back about a capable platform dying away purely because business chose to obsolete it. But we can still be very thankful that we have a legacy of hardware available to us in future systems. I mean look at the Motorola CPUs now, where are they? They were capable, but it's all history now.

My CD-32 CD drive died the other day, could I get a replacement, no.

I also put a bit of the language trade down to translation and that Zarchos is still learning the ropes.

Just posted some videos to 'show' what I was writing about in this thread :
https://youtu.be/X6S4ulzDQuI
https://youtu.be/SAIdCUAr2xM

It's quite ugly and only 'technical', for programmers.

Last video with a CRT monitor, I promise.
https://youtu.be/K44V7ps_tfY

As promised, from now on videos are recorded with an LCD monitor.

https://youtu.be/AHHVMFA9LOE
9 sprites 108x108 pixels, mode 13 320x256, 256 colours, 50 Hz, 50 frames per second, with a 4 channel tune played by QTM.
No unplotting at the moment, and no tricks (each sprite is entirely loaded once, and entirely plotted once).

Enjoy !

Nice! You definitely have big sprites wrapped up. But what I'm more interested in is the sort of specifications you could expect of an 'average' game of the time. For me, Tom Cooper's Hamsters is a great example:





So, what have we got there? Two parallax scrolled layers, 32x32 masked foreground tile sprites, various moving characters of various sizes (mostly smaller than 32x32 it seems), Mode 13, 25fps.

This is what I was aiming for back then, just it had to be 50fps - and I could only manage that by going down into Mode 9. But I still wonder if there might be a way to achieve it on a base Archimedes system (ARM 2; 1Mb RAM, 2Mb at a pinch).

I remember when disassembling Hamsters once, I found it to have a routine much like my routine #2. I don't think it was in any way optimal. I also remember Hamsters' scrolling to be pretty horrible - I think horizontally it only scrolled in 4 pixel increments, using a kind of 'batch scroll' idea (only moving when the character was sufficiently offset from the screen centre).

So how could it be improved?

• Hold 4 pixel shifted versions of the sprites? (with masks?) Would that even fit in 1Mb? Let's assume there are (arbitrarily) 64 background tiles, the minimum I think you'd need for a visually interesting level. That's 64k of sprite data, or 280k if we provide shifted versions; 560k if we have to add a mask! Already looking like it won't fit in a 1Mb machine without some magic. And that's not even counting character and other non-scenery sprites.
• Exploit the fact that background scenery is plotted multiple times on screen, and create sprite routines which repeat a sprite up to 8 times at different screen addresses? That would definitely save on a whole bunch of sprite data loads.
• 'Compile' sprites into ARM code? Would that fit in 1Mb? Would that even win anything for non-transparent sprites?
• Only plot visible background, i.e. not underneath solid blocks of scenery. If done at a coarse level, that might be the most simple win of the lot.
• Fake left/right edge clipping by just defining a slightly wider screen whose edges are hidden by border?

I think it's definitely a difficult problem, but instinct tells me that there probably would have been some way of achieving it, with some compromises, and with some really tricky code. That's what I'd love to hear the answers to. Which compromises would have to be made (number of distinct sprites, sprite size, screen mode, frame rate) in order to achieve as 'arcadey' feel to a game as possible, creating something comparable to the other game systems at the time?