Hi MSX users!
I'm working on a sort of 3D engine, obviously for MSX
It is not comparable with engines available on PC with
last generation 3D graphic boards... it is an experiment, just to try, learn and enjoy.
Working examples are MadFish and 3D-Cube.
I'm evaluating the possibility to develop "something bigger",
I'd like a game resembling Elite (for MSX) and Virus (for Amiga).
I'm looking for people who have:
- motivation, passion and will to do
- Ascii C knowledge
- basic 3D math knowledge
This post has only evaluation purpouse.
Your opinions/comments/suggestions are welcome

Thanks
Marco

well, i have that programmed in BASIC
a figure capable of be rotated 360° in its 3 axis.

and you can to trace lines or point using

XP=0:YP=-1:ZP-1:gosub xxxx <--- for set a point

(all ranges from -1 to 1)

for lines i not remember, but i thinks it is just X2, Y2 Z2 for last point...

it doesn't any mask , so , you needs to draw the things that will be placed in the back taking the point of view of the figure.

well, that just was an experiment like you.

it has zoon control

Translating a 3d coordinate to a 2d screenpoint is piece o' cake .. filling all the polies, and perhaps with some shading or texturising, and all at a decent framerate,.. that's where the headache starts

Actually, there's no headache at all. It just isn't going to happen on an MSX

Quote:

Translating a 3d coordinate to a 2d screenpoint is piece o' cake .. filling all the polies, and perhaps with some shading or texturising, and all at a decent framerate,.. that's where the headache starts

Actually E3D (which could be <E>xperiments in <3> <D>imensions ) supports wireframe polygons, flat painted polygons and linestrips.
Shading is actually in development, texturing is too heavy... probably a full speed one chip MSX1 will be able to do all these wonderful thngs...

Quote:

Actually, there's no headache at all. It just isn't going to happen on an MSX

What about Elite? if you run it on a TR it is quite too fast.
And also Calculus...

Quote:

Quote: Actually, there's no headache at all. It just isn't going to happen on an MSX What about Elite? if you run it on a TR it is quite too fast. And also Calculus...

Well, it's been a while since I've played Elite, but I'm pretty sure I missed the part with the shading and textures!

Quote:

Well, it's been a while since I've played Elite, but I'm pretty sure I missed the part with the shading and textures!

You didn't miss it
Elite has no shading/textures, I use it has example to demonstrate that some 3D stuff is possible on MSX.

If you press <3> and <D> keys in Sandstone main menu you get a mini 3D demo... well I must admit David Heremans is a great programmer

Don't always be so negative... I think, that with customized routines Virus could be done in very playable format. (Anyway I can't suggest calculating the ship in realtime) I played this game on 8086 PC (CGA), but I liked it!

I have also tried to make some 3D stuff on MSX:

http://www.msx.org/modules.php?op=modload&name=Downloads&file=index&req=visit&lid=536

... it is a bouncing box in screen 8 with textures.

Quote:

Don't always be so negative... I think, that with customized routines Virus could be done in very playable format. (Anyway I can't suggest calculating the ship in realtime) I played this game on 8086 PC (CGA), but I liked it!

Thanks NYYRIKKI, good encouragment
I think something like a 3D Bosconian could also be a good option, you have black background, only starfields to give the sensation of movement and with clever programming you could limitate the number of visible objects.

Quote:

I have also tried to make some 3D stuff on MSX:

Really nice, never seen it before...
wouldn't you like to "join E3D project"?

It's a very nice demo nyyrikki, but it's still a far cry from a minimum 15fps a game like elite would require. You'd save a little time by using screen 5 and doing the whole thing in assembly, but I still doubt it would be possible to do 3D on MSX with texture mapping. Perhaps a Turbo-R could do it, but still, I'd be surprised to see anything other than filled polygons with perhaps a little z-axis shading.

Still, go for it! I'm sure you could remake Elite into an even better game without needing to do tricks like that anyhow. I'm sorry to say I don't speak C though, plus I'm terrible at math in assembly...

on other way, which is the generic 3d to 2d plus Z coordinates formula?

when i does the one that i do, i use only multiplications and AND / OR plus some SIN() nothing more.

but i not get the perfection that i was finding in that time, so, i drop the proyect.

i remember i dividel the formula in two stages. ONE executed one time per frame or each time that the point of view changes. This one calculates 9 raw values, for the usage of the second a little formula.



the other is executed for each point to draw. And is too simply like

XS= (XP*XX + YP*YX + ZP*ZX) * ZO + XC
YS= (XP*XY + YP*YY + ZP*ZY) * ZO + YC
ZS= (XP*XZ + YP*YZ + ZP*ZZ)

where XC, YC is the offset to aims to the center of the screen while XP,YP,ZP = 0.

XP , YP , ZP is the 3D coordinates of the point to draw.

ZO = zoom (its value is the half of the size of the window use for the drawing), negative value just flips the draw.

XS,YS is the screen coordinate for the point
ZS is the Z position on the screen to use this value for masking purposes.


XX, XY, XZ, YX, YY, YZ, ZX, ZY, ZZ are raw values precalculates. Its means, means

By example:

"XY" = In which amount (or level) the (X position 3D) will affects the Y position on the screen.

where the first leter is the 3D position, and the second leter is the effect on the screen.

Those raw values are precalculated one time per frame or each time that the point of view changes. Zoon or offset screen changes will NOT needs to precalculating again.

And the heavy where SIN() and a lot of * and logical part are, are in the first formula.

screenx=x/z
screeny=y/z

just make damn sure z is never zero

The rotations are not included here.. this is purely the translate xyz to xy

the first formula gets

XA,YA,ZA (x,y,zAgle) for set the point of view.

where XA,YA,ZA =0 the screen axis match with the 3D axis.

the range of XA,YA,ZA is -1 up to 1

i did too a assembler version where XA,YA,ZA has the range from 0-255 but since the original formula in MSXBASIC was not perfectioned.... in assembler the thing come worst by redundancy errors.

tomorrow i will dump here the msxbasic formula... i hope this can be improved.

how i did the formula...

i get 3 pencils, and tape scouch, i joins the 3 pencils in its half part.... at its points i mount labels "-XP" "+XP" "-YP" "+YP" "-ZP" "+ZP".... and i imagine than my point of view (always since front) was the screen.... so, i start rotating the pencils (or angle axis), and watch to where the labels goes... so i take notes of all, and make a table with that...

that was the easy part...

the second was to imagine the formula that does the same thing that the pencils rotated does.

first i gets a huge formula, but i watch it and see that some redundancy things, and start to compressing it, a lot.

at last i get like 6 msx lines or maybe 5.... no more than 40 chrs each one....

but as i said, the formula is not perfect

when you drawn a cube, and watch it rotating.... (maked point per point) you can see how the cube rounds its borders, it is not perfect linear. But it does when two or the three axis of the point of view are near or fall in 45° in any direction .....

so, there is when all turns too complicated for me.... that i am just an amateur in maths.