Amiga.org
Amiga computer related discussion => Amiga Gaming => Topic started by: Speelgoedmannetje on November 30, 2003, 03:40:33 PM
-
You know, the engine used in Novalogic games like Comanche
Couldn't that be realised on a unupgraded Amiga (A1200, CD32)?
-
Speelgoedmannetje wrote:
You know, the engine used in Novalogic games like Comanche
Couldn't that be realised on a unupgraded Amiga (A1200, CD32)?
Only very very slowly, and in low resolutions.
Voxel is quite the realization of byte-per-pixel (chunky) display routines that the Amiga isn't very good at, natively. Now an inexpensive Graffiti external "graphics card" would make it easier. However I don't think these were ever very popular.
-
B00tDisk wrote:
Only very very slowly, and in low resolutions.
Voxel is quite the realization of byte-per-pixel (chunky) display routines that the Amiga isn't very good at, natively. Now an inexpensive Graffiti external "graphics card" would make it easier. However I don't think these were ever very popular.
The CD32 would be soemwhat faster, as it has the Akiko-chip for C2P-conversion.
-
But can the Akiko chip make it fast
-
No , it would be a 10% increase at best.
The miggy needs something liek the good ol' SWIW 3D engine. It should run nicely on a 060.
-
Because the Amiga is fast @planar, with the CD32 specially designed to handle those chunky thingies to planer you'd say that 'd be fast too
-
@Whabang
Quite dissapointing, that's a lame speed increase
-
Aaaaah..novalogic, creators of one the games I wasted many an hour on. Wolfpack...anyone remember that? Very good (well back then anyway) u-boot game. How I loved that dive alarm :-).
-
@odin
I allways preferred Aces of the deep... :-)
-
Speelgoedmannetje wrote:
@Whabang
Quite dissapointing, that's a lame speed increase
Well, on a 020 it will probably be higher...
-
The question isn't really about the C2P-conversion. The real problem is to get the chunky data to convert. The 68k-series is simply not enough. :-(
-
But the CD32 has a 020 and a chunky to planar chip.... :-?
-
And the 020 isn't much of a CPU.....
-
The (in short 020) 68020 not a CPU?
-
It is, but it just isn't very powerfull. Even by mid-90's standards.
-
I have often wondered about voxel engines on the amiga chipset...
Consider the onscreen representation of your average voxel. Its basically a rectangular block of solid colour. Far away voxels reduce to single pixel widths, but they are still typically vertical lines of solid colour...
So, heres a thought experiment...
Could an AGA hardware bashing engine use the blitter to render these voxels into chipram directly whilst the CPU is calculating the next one to draw?
Assume A smart implementation could calculate the visible on screen length of the voxel to avoid overdraw by the blitter.
Thoughts?
-
You know, the engine used in Novalogic games like Comanche Couldn't that be realised on a unupgraded Amiga (A1200, CD32)?
Theoretically, it would be possible. But the number of possible voxels on-screen would be even lower than in Comanche, thus the game should look rather ugly.
There was a game called "Shadow Of The Third Moon" which was similar to the old Comanche. The graphics were okay, but it required at least a 030 processor and 4MB of FastRAM. (It ran fine on this type of hardware configuration, though.) So, if you have an SX32/4MB or some other hardware extension for your CD32, you might even be able to play the game.
-
@Karlos
Those were exactly my thoughts too
-
@Andre.Siegel
Those specs seem to me reasonable
-
Speelgoedmannetje wrote:
@Karlos
Those were exactly my thoughts too
So chip fiends, whats the pixel fill rate of the AGA blitter in 256 colour mode?
-
Karlos wrote:
Speelgoedmannetje wrote:
@Karlos
Those were exactly my thoughts too
So chip fiends, whats the pixel fill rate of the AGA blitter in 256 colour mode?
It's hard to give an accurate figure... but it's more or less as slow as a dead snail...
-
Ok, assume 320x200 64 colours then.
Next up assume that only foreground voxels (anything > 1 pixel wide) are rendered witht the blitter and the rest is done by CPU, if faster...
-
Karlos wrote:
Ok, assume 320x200 64 colours then.
Next up assume that only foreground voxels (anything > 1 pixel wide) are rendered witht the blitter and the rest is done by CPU, if faster...
The best performace on the AGA Blitter was a 320*200*4 (ie 16 colours).
The Blitter and CPU can't reneder at the same time since they both have to access Chip RAM to do it. when I ws playing with such things, I found it was much quicker to rend the whole thing in Fast RAM chunky, then C2P, then copy the whole thing over in one go using a movem loop.
-
bloodline wrote:
The Blitter and CPU can't reneder at the same time since they both have to access Chip RAM to do it. when I ws playing with such things, I found it was much quicker to rend the whole thing in Fast RAM chunky, then C2P, then copy the whole thing over in one go using a movem loop.
I know they cant render at same time, I was thinking a two pass job if mixing the rendering between blitter and CPU.
It would be interesting to see if a blitter driven voxel engine is remotely feasable, but I'm not the AGA basher to do it :-(
-
Karlos wrote:
bloodline wrote:
The Blitter and CPU can't reneder at the same time since they both have to access Chip RAM to do it. when I ws playing with such things, I found it was much quicker to rend the whole thing in Fast RAM chunky, then C2P, then copy the whole thing over in one go using a movem loop.
I know they cant render at same time, I was thinking a two pass job if mixing the rendering between blitter and CPU.
It would be interesting to see if a blitter driven voxel engine is remotely feasable, but I'm not the AGA basher to do it :-(
Well I gave up trying to do 3D with the Amiga Chipset, it simply isn't designed for it.
-
I hear you there, but lets face it, voxels arent exactly 3D in the sense that requires a polygon rasterizer..
-edit-
In fact, you need fast 2D block fills really ;-)
-
But the pixels need to be placed 3d...
-
Speelgoedmannetje wrote:
But the pixels need to be placed 3d...
Well, you are thinking of geometry transformation. For voxel engines, such calculations are for the CPU. True 3D engines may emply hardware for this on systems that have it.
For voxels, the result of these calculations are the onscreen dimensions of the 2D 'boxes' that are drawn on screen. This is what I was musing that the AGA blitter might be able to handle ok...
-
Karlos wrote:
Speelgoedmannetje wrote:
But the pixels need to be placed 3d...
Well, you are thinking of geometry transformation. For voxel engines, such calculations are for the CPU. True 3D engines may emply hardware for this on systems that have it.
For voxels, the result of these calculations are the onscreen dimensions of the 2D 'boxes' that are drawn on screen. This is what I was musing that the AGA blitter might be able to handle ok...
I think you will find setting up the blitter to try and draw squares on the screen takes longer than using the CPU to render everything in a fast ram Frame buffer and then use a fast CPU copy loop to pump the frame buffer into the chip ram.
This is true on an 030 at least (I never had an 020 with fast ram to test).
If you want to blit large shapes on the screen (ie 2D games sprites), then the blitter is fine, but other than that I found it quite useless. :-)
-
Well, you know, this was an old old idea from times when 68020 + fast ram was kinda high spec :lol:
-
I was thinking a two pass job if mixing the rendering between blitter and CPU.
Setting up blitter to fill a rectangle is complex. Also to draw rectangle with specific colour you typically need to do 8 blits (for 256 col screen). Consider drawing 800 voxels: That would result in 800*8 = 6400 blits, and each one would have different individual setup.
Two pass routines mixing CPU and blitter only pay off when the actual blit is done only in few large operations. Also ever since 040, using CPU only has been faster. In fact, I remember that even with 030 it was faster with CPU only.
It would be interesting to see if a blitter driven voxel engine is remotely feasable, but I'm not the AGA basher to do it
No, it's not.
-
Oh well...I guess that puts paid to that idea :-)
You can see why I started doing graphics post RTG only :-)
-
Karlos wrote:
Oh well...I guess that puts paid to that idea :-)
You can see why I started doing graphics post RTG only :-)
I used to believe, as you did, that the AGA was able to cope with it... only after a few months of trying everthing I could think of did I come to the conclusion that my 030 was actually better than the Blitter :-)
-
Dang! We ain' nuffin but a pair o' poor misguided fools!
-edit-
When I get a mo, I'm gonna hardware bash my BVision. I'm sure the Permedia2 can outfill my 68040 for say 800x600x16-bits...
Just send a mass of rectangle requrests into the FIFO...
hehe :-)
-
But if I am looking at a game like ElfMania, there are a hell of a lot independently moving pixels to be drawn . And that's running on a 1mb A500
Let's see, the A500 came out in 1988 and the A1200 in 1992, so after 4 years, a hell of a lot more pixels could be drawn couldn't it?
-
Well, we are talking about block fills using the blitter. As the guys have explained, it is neither fast at doing this and at same time you'd need many thousands of them for any reasonable voxel engine...
-edit-
What a bummer...back in the day it seemed a good idea too :lol:
-
Karlos wrote:
Well, we are talking about block fills using the blitter. As the guys have explained, it is neither fast at doing this and at same time you'd need many thousands of them for any reasonable voxel engine...
-edit-
What a bummer...back in the day it seemed a good idea too :lol:
I've seen screen shots of your game engine... what frame rate did that get? I assume you used intuition/cybergraphics?
-
@bloodline
It varied :-) It was mostly a learning exercise and if I was to do it again, I'd avoid many pitfalls of last time....(famous last words - I'd just find new pits to fall into :lol: ).
First up, it was running on 68040 and was using OS standard stuff + cxg +warp3d (v3 funcs only).
A lot of overhead was from having to call the warp3d v3 functions for so many small sets of polygons. v4 is far better for this (one call can render as much as you can give it).
It ran at ~15fps when you were at the default zoom level. As you zoom out or go for a shallow view (anything basically increasing the number of cells to vis test and render) it got slower. To help things along, many detail objects and stuff 'faded out' and stopped being rendered all together beyond a certian long distance zoom level.
Similarly it got faster as you zoomed in, so I added extra passes for detail textures and stuff to take advantage.
One thing it used was a transformation cache. Given the nature of the engine I anticipated that the view wouldnt change much, most of the time youd be clicking on stuff and doing stuff locally then scrolling over somewhere else and fiddling about there.
Hence, only when the view changed was all the visible stuff recalculated, then reused until another change occured (for the static world/objects only, of course). So when you werent moving around it was very steady - the water ripplinng was hypnotisingly smooth ;-)
Anyhow, it ran on my first experimental portability layer project, but that in itself was canned (as it was frankly rather poo). My new portability layer doesnt have enough functionality yet and I am too busy to work on it for now, but its much cleaner, better designed - and most importantly faster :-)
Rather than upwards port that old engine, I'd write something new instead :-)