168 replies to this topic

[emkay]

We all may know this one:




Check this one from CPC , it's the closest comparable demo.



8 Bit 3D .
Pure CPU power (4MHz) vs. 1.79MHz CPU with Coprocessor.


What do you think?

Edited by emkay, Mon Nov 28, 2011 3:00 AM.

[emkay]

Isn't interesting to have some early 8 bit computers being able of showing real 3D ?

[emkay]

I wonder, If we could get some of those coders doing stuff on th A8. As the A8 could benefit by the knowledge of 3D programming via CPU.
It also seems, they don't care about Sprites and VBI, just clean CPU programming.
I also wonder what they could get out of the A8.

[Heaven/TQA]

yeah... but Z80 is different from 6502 but why not?

[TMR]

If you watch Midline Process all the way through, the coder talks about how it's done:

Midline Process, on Mon Nov 28, 2011 6:56 AM, said:

The movie

It is made of two thousand and four hundred frames. All was modelled on PC of course. Each frame is saved as a BMP, then resized with 'Batchit' then converted to RAW RGB using Paintshop Pro. Finally, I converted them to some kind of Delta RLE with a code of my own.

The one who says all this could be done on CPC is a fool and a liar...

[emkay]

Yeah....
Should have watched it to the end
I saw other demos on the CPC with fast 3D animations where it was clearly a "movie" .
I wonder why the CPC shouldn't be able to make those 3D scenes. It's rather slow for a movie - as such - and it shows tearing.
The coder acts interesting aswell. Let's move the CPC clouds on the sky, and tells it cannot change the weather

Someone should contact him and show the Atari Demo

Edited by emkay, Mon Nov 28, 2011 12:10 PM.

[TMR]

emkay, on Mon Nov 28, 2011 12:10 PM, said:

I saw other demos on the CPC with fast 3D animations where it was clearly a "movie" .
I wonder why the CPC shouldn't be able to make those 3D scenes. It's rather slow for a movie - as such - and it shows tearing.

A 4MHz Z80 is very approximately the equivalent of a 2MHz 6502 so the Amstrad is only clocked slightly faster than the A8... and then it's got at least twice as much screen RAM to deal with.

emkay, on Mon Nov 28, 2011 12:10 PM, said:

The coder acts interesting aswell. Let's move the CPC clouds on the sky, and tells it cannot change the weather

It's commonplace for 8-bit demo coders to find the fastest possible way to appear to be doing something and then abuse the hell out of it for best effect; the majority of demos will be pre-calculated and that can be storing the entire frame, RLE/delta compressing pre-generated frames, keeping the co-ordinates of each polygon for a draw routine to draw in realtime... all of these aren't doing a single 3D calculation on the fly and can be either running from RAM or streamed from floppy. Very few real 3D environments exist in 8-bit demos and it's a fairly safe bet that pre-calc is involved unless the programmer gives a joystick-controlled version out at some point or hides a manual option in the demo itself.

[emkay]

TMR, on Mon Nov 28, 2011 1:34 PM, said:

emkay, on Mon Nov 28, 2011 12:10 PM, said:

I saw other demos on the CPC with fast 3D animations where it was clearly a "movie" .
I wonder why the CPC shouldn't be able to make those 3D scenes. It's rather slow for a movie - as such - and it shows tearing.

A 4MHz Z80 is very approximately the equivalent of a 2MHz 6502 so the Amstrad is only clocked slightly faster than the A8... and then it's got at least twice as much screen RAM to deal with.

Let's say , the Amstrad CPU is clocked 2.4 times faster than the A8 (when using the low resolution mode).
Calculations should be faster with the Amstrad, and the Zilog CPU has some nice 16 bit commands to handle the 16 bit framebuffer (just copy screendata).

[TMR]

emkay, on Mon Nov 28, 2011 2:08 PM, said:

Let's say , the Amstrad CPU is clocked 2.4 times faster than the A8 (when using the low resolution mode).

That would be a major slight to the A8, at a hideously rough estimate the CPC is around 20-30% faster and nowhere near double.

emkay, on Mon Nov 28, 2011 2:08 PM, said:

Calculations should be faster with the Amstrad, and the Zilog CPU has some nice 16 bit commands to handle the 16 bit framebuffer (just copy screendata).

Calculations should be faster because it can perform them using 16 bit register pairs, but getting to memory is a bit more convoluted; the 65xx equivalent would be to always use indirect indexed addressing rather than the faster indexed addressing modes (or self modifying code). The CPC frame buffer isn't linear either, so calculations to get from line to line take some extra cycles, and if you compare equivalent displays there's about twice as much of it.

[emkay]

TMR, on Mon Nov 28, 2011 2:45 PM, said:

Calculations should be faster because it can perform them using 16 bit register pairs, but getting to memory is a bit more convoluted; the 65xx equivalent would be to always use indirect indexed addressing rather than the faster indexed addressing modes (or self modifying code). The CPC frame buffer isn't linear either, so calculations to get from line to line take some extra cycles, and if you compare equivalent displays there's about twice as much of it.

Checking some papers of the Amstrad's Video Chip, it has a fully working character "handler". Using this directly, releases the CPU from any colour handling.
In theory it acts like a "char - Blitter" , not causing the CPU to stop. I wished the A8 had this in the Antic

[CharlieChaplin]

TMR, on Mon Nov 28, 2011 1:34 PM, said:

It's commonplace for 8-bit demo coders to find the fastest possible way to appear to be doing something and then abuse the hell out of it for best effect; the majority of demos will be pre-calculated and that can be storing the entire frame, RLE/delta compressing pre-generated frames, keeping the co-ordinates of each polygon for a draw routine to draw in realtime... all of these aren't doing a single 3D calculation on the fly and can be either running from RAM or streamed from floppy. Very few real 3D environments exist in 8-bit demos and it's a fairly safe bet that pre-calc is involved unless the programmer gives a joystick-controlled version out at some point or hides a manual option in the demo itself.

Yeah, true.

But, take a look at "Ergo Bibamus" (a collection of realtime effects) and its last part showing a cityscape (or a village). You can stop the automatic "flying" over it and use Start, Select and Option to manually fly around (not sure if a joystick is also supported)...

The dungeon-parts of "Numen" (also known as "Vector") can also be found seperately as single files, one can walk around there... not to forget "Project-M"...
-Andreas Koch.

Attached Files

•  ERGOBIB.zip   100.7K   22 downloads
•  VECTOR.zip   22.92K   19 downloads

Edited by CharlieChaplin, Mon Nov 28, 2011 4:00 PM.

[TMR]

CharlieChaplin, on Mon Nov 28, 2011 3:58 PM, said:

But, take a look at "Ergo Bibamus" (a collection of realtime effects) and its last part showing a cityscape (or a village). You can stop the automatic "flying" over it and use Start, Select and Option to manually fly around (not sure if a joystick is also supported)...

The dungeon-parts of "Numen" (also known as "Vector") can also be found seperately as single files, one can walk around there... not to forget "Project-M"...

That's why i said "very few", there are exceptions of course but they're certainly in the minority. i can't think of more than half a dozen in total over the various 8-bits and Vector was already on that list. These parts usually suffer a bit on the refresh speed front for that interactivity as well...

Project M isn't really a demo in this context, it's a game and that's a very different mindset to code.

Edited by TMR, Mon Nov 28, 2011 4:22 PM.

[Heaven/TQA]

oh... need to check the CPC video chip specs, too... I was under the impression that

a) direct access not like on MSX
b) 16k for all data
c) non-linear
c) no scrolling

need to read a doc...

if so... it becomes difficult and explains some "crappy" games...

[Rybags]

It uses the 6845 like BBC but in a slightly different way.

Scrolling is somewhat irrelevant since it's not of much use for 3D stuff.

So it's down to ability to put stuff onscreen, of course the handicap is that if a more colourful mode is used then it's pretty much double the data of Antic E or F.

"Crappy games" - well, no sprites, much lesser ability to do scrolling or set the screen base.

[emkay]

TMR, on Mon Nov 28, 2011 4:21 PM, said:

CharlieChaplin, on Mon Nov 28, 2011 3:58 PM, said:

But, take a look at "Ergo Bibamus" (a collection of realtime effects) and its last part showing a cityscape (or a village). You can stop the automatic "flying" over it and use Start, Select and Option to manually fly around (not sure if a joystick is also supported)...

The dungeon-parts of "Numen" (also known as "Vector") can also be found seperately as single files, one can walk around there... not to forget "Project-M"...

That's why i said "very few", there are exceptions of course but they're certainly in the minority. i can't think of more than half a dozen in total over the various 8-bits and Vector was already on that list. These parts usually suffer a bit on the refresh speed front for that interactivity as well...

Project M isn't really a demo in this context, it's a game and that's a very different mindset to code.

But particular Project-M turns all your argues over
It is even faster than "all demos", it IS "interactive" and so on.

[emkay]

Rybags, on Tue Nov 29, 2011 1:04 AM, said:

"Crappy games" - well, no sprites, much lesser ability to do scrolling or set the screen base.

It's more the problem how it was used, and as it seems, it has been locked by the programming ROM (OS).
Because several stuff is possible, just like full overscan, hardware scrolling , and interlace.
The chip is also way faster connected than the MSX.

Just a reminder:

[media][media]

Fullscreen (incl. overscan) hardwarescrolling , and no tearing in sight .

[sack-c0s]

emkay, on Mon Nov 28, 2011 2:08 PM, said:

TMR, on Mon Nov 28, 2011 1:34 PM, said:

emkay, on Mon Nov 28, 2011 12:10 PM, said:

I saw other demos on the CPC with fast 3D animations where it was clearly a "movie" .
I wonder why the CPC shouldn't be able to make those 3D scenes. It's rather slow for a movie - as such - and it shows tearing.

A 4MHz Z80 is very approximately the equivalent of a 2MHz 6502 so the Amstrad is only clocked slightly faster than the A8... and then it's got at least twice as much screen RAM to deal with.

Let's say , the Amstrad CPU is clocked 2.4 times faster than the A8 (when using the low resolution mode).
Calculations should be faster with the Amstrad, and the Zilog CPU has some nice 16 bit commands to handle the 16 bit framebuffer (just copy screendata).

That's a rubbish way of looking at it - your average Spectrum/Amstrad fan would like to tell you that their CPU is 2x faster because of the clock speed, but the 6502 is more efficient with its instruction handling so tends to finish in half the cycles anyway. The 16-bit registers give it a bit of an edge, but not so much really. It makes it a little easier to code for, but not so much faster. Z80s tend to be very prone to memory contention issues - hence the popularity of chips like the TI graphics chips in the MSX/Sega Mastersystem that give the graphics memory its own bus and are written to through an I/O port (which can be a bit limiting for doing non-tilebased stuff, like bitmap screens because the bandwidth to write to it is limited).

It's like judging how fast your car is going by looking at the rev counter - A z80 is like going down the motorway in 3rd gear, hitting the red line (50,000RPM?), and a 6502 is like doing it in 5th gear at a more comfortable 35,000RPM. Both would still be about neck-and-neck doing 70MPH/120KMH

[TMR]

emkay, on Tue Nov 29, 2011 1:21 AM, said:

But particular Project-M turns all your argues over
It is even faster than "all demos", it IS "interactive" and so on.

It doesn't really break my argument because there are other factors that have to be considered such as which rendering engine is in use, how old the code is, if anything else is moving through the "world", is the engine actually a renderer in the first place rather than a streaming animation and so on. Project M is of course impressive, but Vector is dealing with a more complex environment and camera moves, so takes a hit on performance for those features. Comparing like for like is very difficult in these situations.

[Creature XL]

TMR, on Tue Nov 29, 2011 4:14 AM, said:

emkay, on Tue Nov 29, 2011 1:21 AM, said:

But particular Project-M turns all your argues over
It is even faster than "all demos", it IS "interactive" and so on.

It doesn't really break my argument because there are other factors that have to be considered such as which rendering engine is in use, how old the code is, if anything else is moving through the "world", is the engine actually a renderer in the first place rather than a streaming animation and so on. Project M is of course impressive, but Vector is dealing with a more complex environment and camera moves, so takes a hit on performance for those features. Comparing like for like is very difficult in these situations.

Reading posts of emkay it should be obvious that he doesn't know the difference between real 3d, ray casting and the arctan-tunnel-stuff yoomp, does. So we should either explain it or leave him alone.

If I am not mistaken the coder of yoomp wrote here that the only problem he had, was where to put all the tables he uses.

[emkay]

Creature XL, on Tue Nov 29, 2011 12:25 PM, said:

TMR, on Tue Nov 29, 2011 4:14 AM, said:

emkay, on Tue Nov 29, 2011 1:21 AM, said:

But particular Project-M turns all your argues over
It is even faster than "all demos", it IS "interactive" and so on.

It doesn't really break my argument because there are other factors that have to be considered such as which rendering engine is in use, how old the code is, if anything else is moving through the "world", is the engine actually a renderer in the first place rather than a streaming animation and so on. Project M is of course impressive, but Vector is dealing with a more complex environment and camera moves, so takes a hit on performance for those features. Comparing like for like is very difficult in these situations.

Reading posts of emkay it should be obvious that he doesn't know the difference between real 3d, ray casting and the arctan-tunnel-stuff yoomp, does. So we should either explain it or leave him alone.

If I am not mistaken the coder of yoomp wrote here that the only problem he had, was where to put all the tables he uses.

Don't interpret things wrong. Ofcourse he used Gr.7 to save memory. But the sideeffect is the workable graphics-speed he got, and not had with Gr. 15.
"Accidently" he got 2.55 cycles per Pixel, or 10.2 cycles per byte to change. Instead of 1.175 cycles per Pixel, which means 4.7 Cycles per byte to change.
So in gr. 7 you can change the full screen content easily, on the fly. Even when using 48 bytes and 240(120) lines. There is even time left to change some audiochannel.... for digi, you know

Edited by emkay, Tue Nov 29, 2011 12:54 PM.

[José Pereira]

Emkay, what about this:

Would you use GR.7 here?

Or would you use the Tezz Silk Worm idea with, probably, Amiga/ST/P.C. gfxs. in ANTIC4 and PMs. underlays for the sprites?

Edited by José Pereira, Tue Nov 29, 2011 1:14 PM.

[TMR]

emkay, on Tue Nov 29, 2011 12:52 PM, said:

Creature XL, on Tue Nov 29, 2011 12:25 PM, said:

Reading posts of emkay it should be obvious that he doesn't know the difference between real 3d, ray casting and the arctan-tunnel-stuff yoomp, does. So we should either explain it or leave him alone.

If I am not mistaken the coder of yoomp wrote here that the only problem he had, was where to put all the tables he uses.

Don't interpret things wrong. Ofcourse he used Gr.7 to save memory. But the sideeffect is the workable graphics-speed he got, and not had with Gr. 15.

He's not talking about the decision to run it in that resolution but the way the 3D is handled; i haven't read that post about how Yoomp! is done, but i've always assumed it was using what some demo coders call a movelist, in which case there's no 3D maths taking place during play and the shape of the tunnel is pre-calculated. If that's right (and i'll reiterate here that i'm guessing somewhat) then there's nothing to stop the play area being octagonal, square, in perspective similar to Trailblazer or wrapped around a sphere if the table is rebuilt.

[Heaven/TQA]

It is movelist... No 3d calculations at all... For what? Now I even say that it is a 2d game at all. Did I not say that years ago in terms that it is trailblazer?

[emkay]

Heaven/TQA, on Tue Nov 29, 2011 2:59 PM, said:

It is movelist... No 3d calculations at all... For what? Now I even say that it is a 2d game at all. Did I not say that years ago in terms that it is trailblazer?

It's in the definition.
It is an ego view game, doing 360° tile zooming to show depth movement. But it isn't simply using some Raster FX to show some depth impression.
It acts like a modern PC, which is doing this with textures, showing them smaller in the distance, making them bigger when it gets closer.
Following your definition, the PC also uses only a movelist.

[Heaven/TQA]

yes... it is definition...

Elite is a 3d-game, Stunt Car Racer is a 3d Game, Mercenary is a 3d-Game... Maybe even Alternate Reality is a 3D game... maybe Star Raiders... Rescue on Fractalus/Koronis Rift/Eidolon... imho little bit Ballblazer.

inmho Yoomp is not a 3d game at all... the Player moves in 1 Axis only... X-axis... the tube is a 2d plane in memory... so Yoomp could be ported to 2600 with top-view and the game mechanics would be the same.