Doing 3D games on the Oric ?

Want to talks about games you like, would like to see developed on the Oric, it's here.
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Doing 3D games on the Oric ?

Post by Dbug »

And yes 3D vector graphics is not easy, but that's really interesting !
On the few attempts I made in the past, my biggest problem was more in transforming/projecting the points in space than displaying the result on screen.

Found out also that drawing everything directly on screen, but doing double buffering by playing with odd/even lines both resulted in nice frame rates and memory efficient stuff :)

Basically:
- Put all screen with BLACK INK attributes in the left column
- Draw the 3d data on the even lines of the screen
- Set all even lines of the screen to WHITE INK -> 3d data appear
- Draw the next frame on the odd lines of the screen
- Set all even lines of the screen to BLACK INK while setting all odd lines to WHITE INK
- Repeat and rinse :)

Advantage is that there is no back buffer to copy, and animation happens only on half the screen, so it's not that bad from a performance point of view.

The big problem is as always to optimize the amount of redrawing/erasing
User avatar
Twilighte
Game master
Posts: 819
Joined: Sat Jan 07, 2006 12:07 am
Location: Luton, UK
Contact:

Post by Twilighte »

Interesting use of alternate lines, although i would have preferred using a buffer but still use alt lines to achieve colourful graphics.

Perhaps the 25% loss of speed thru Orics 6 pixel byte format may be replenished by using alt lines and facilitate such games as Driller or Elite? :P
Dbug wrote:Repeat and rinse
haha
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

Problem of buffer is that it kills performances.
In 3D you don't really have control of where are things when the camera moves, so you may well have to refresh the whole screen, and at this point your frame rate can basically be called "slide show" :)
User avatar
Twilighte
Game master
Posts: 819
Joined: Sat Jan 07, 2006 12:07 am
Location: Luton, UK
Contact:

Post by Twilighte »

It would be interesting to see how 3D was achieved on other machines then. For example screen banking was not available on every other computer yet (it seems) every other computer had some very successful 3D games, such as the BBC, Spectrum, Commodore 64, Amstrad CPC.
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

Twilighte wrote:It would be interesting to see how 3D was achieved on other machines then. For example screen banking was not available on every other computer yet (it seems) every other computer had some very successful 3D games, such as the BBC, Spectrum, Commodore 64, Amstrad CPC.
Yep. Elite was originally for BBC (IIRC), written in a super-BASIC that allows inline 6502 asm too :) and then ported to many machines like Spectrum or Commodore 64, so I guess it should be doable in an Oric.

The wire-3D models where simple, and I think I recall many drawing errors when things overlapped (stars and ships also). So I guess they just draw the polygons, erase the lines and draw again to move objects in 3D.

I think this could be a very nice game to port. There are sources out there, including a C version of the market & universe engine (everytihing but graphics and action -- no pirates or enemies out there). Surely it should be converted to 6502 anyway...

Cheers.
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

Now imagine, you port the Elite engine, and do a cross breeding with Space: 1999, to actually have real space stations you can visit :p

I considered porting Elite myself some years ago when the sources were published, but this hybrid of Basic and inline assembler was too weird for my taste :)
User avatar
Symoon
Archivist
Posts: 2307
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France

Post by Symoon »

Dbug wrote:Now imagine, you port the Elite engine, and do a cross breeding with Space: 1999, to actually have real space stations you can visit :p
That would be called Mercenary :-)
http://mercenarysite.free.fr/m1pics.htm
User avatar
Egg Shen
1st Star Corporal
Posts: 8
Joined: Fri Jul 13, 2007 10:01 am
Location: France (30)

Post by Egg Shen »

Mercenary !
Wow, it brings back old memories, a friend had this game on his CPC 464, and on the Amstrad version of the game you could desintegrate traffic signs with the Atari et Commodore logos !

However, it was a cool game. :)
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

I am not sure how they did it, but it must be possible on an Oric too... even if it is at a slower pace.

I bet they erased a line by plotting it again setting bits to 0... If you have a put_pixel routine which performs an eor instead of an ora with the screen content, you can do it easily.

I have tried to do something in 3D before, with real projections. Only a set of points moving towards the screen, like a starfield. I was able to move 120 dots at a reasonable speed, and I am sure this can be optimized...

Once the 3D vertex are projected in the screen, it is a matter of drawing the polygons (having a very quick line routine, I suppose)...

There are zillions of problems here, but it is indeed quite a challenge!

When I have time, I will give a look at this problem and see if I figure out how it can be dealt with :)

Cheers.
User avatar
Twilighte
Game master
Posts: 819
Joined: Sat Jan 07, 2006 12:07 am
Location: Luton, UK
Contact:

Post by Twilighte »

We do have some very fast line drawing routines now. And i have somewhere a fast circle drawing routine (note circle and not ellipse).
As Dbug has said before, the major problem is that the Oric has no ability to screen switch.

The problem with BBC Elite is as follows
Whilst the BBC version of Elite was indead written in something approaching 24K of memory (every last byte squeezed!) it was done in Mode 0 graphics (thats 640x200 i think) and in 2Mhz mode.

I think the spectrums Screen can be banked to another part of memory, which facilitates 3D graphics alot. Also the Z80 even at 3.5mhz zips along alot faster than other 8 bit micros.

The Commodore 64 definately has screen switching and the sprites may have been used to speed up the animation of Elite crafts.

I also think the Amstrad had Screen bank switching.

Certain techniques can be employed on the Oric to simulate Screen switching, as Dbug proved with his sinus wave, but producing large 3D graphics may prove impossible since as far as i know (and he may destroy me for saying this) he dynamically redefines the character set to provide the sinus line.

It is possible to set up two switchable screens on the Oric but of limited vertical and horizontal resolutions.
We have 96 available characters in standard text and 80 in alternate text.
This could provide a screen resolution (using double height characters) of 192x80 (32x10).

It may also be possible to add a false HIRES switch(HIRES switch then text switch in same line) but in so doing fooling the ORIC into switching the character set to its HIRES set for some lines. This would allow a further 12 text rows to be used.

So technically we will eventually have a minimal text screen that may have a bitmap resolution of 192x80.
We then use another HIRES switch to switch to real HIRES and this provides the two screen banks.
The major headache of these areas is that they are not mapped in the same way. One uses 6x8 cells organised in text rows and the other 6x1 cells in HIRES rows.
However both bitmaps would need (at the lowest level) a fast pixel drawing routine and two versions could be written for the two modes.
Here is a basic type-in to generate at least some of the above..

Code: Select all

 5 HIRES:TEXT
 10 CLS:FORA=0TO31
 20 PLOT4+A,1,32+A
 30 PLOT4+A,2,32+A
 40 PLOT4+A,3,64+A
 50 PLOT4+A,4,64+A
 60 PLOT4+A,5,96+A
 70 PLOT4+A,6,96+A
 80 PLOT4+A,7,32+A
 90 PLOT4+A,8,32+A
 91 PLOT4+A,9,64+A
 92 PLOT4+A,10,64+A
 94 NEXT A
 100 REM SET ALT DBLHEIGHT
 110 FOR A=7TO10:PLOT3,A,11:NEXTA
 120 REM SET STD DBLHEIGHT
 130 FOR A=1TO6:PLOT3,A,10:NEXTA
 132 POKE#BFDF,28
 135 GOSUB 200
 140 POKE#BFDF,28:WAIT50
 150 POKE#BFDF,32:WAIT50
 160 GOTO 140
 200 REM CONVERT TEXT TO HIRES
 210 FOR Y=1 TO 10:FORX=4TO35
 220 P=PEEK(#BBA8+X+Y*40)
 230 IF INT(Y/2)=Y/2 THEN E=1 ELSE E=0
 240 IF Y>6THEN C=#B800+8*P ELSE C=#B400+8*P
 250 FOR O=0TO7
 252 IF E=0 THEN Z=C+(O/2) ELSE Z=C+4+(O/2)
 255 POKE41280+X+(Y*320)+(O*40),PEEK(Z)OR64
 260 NEXTO:NEXTX:NEXTY:RETURN
Tap link below.
The program draws the text screen (20-130) then converts it to HIRES(200-260) and finally switches between screens (140-160).

http://www.defence-force.org/ftp/forum/ ... /sbank.tap

All this does have some rather undesirable limitations
1) pixels are 1x2 (double height)
2) screen area limited
3) Eats up most characters so border graphics are difficult.

Damn, i'm sure i will have upset Dbug somewhere above. Whilst i fondly think my techniques may be original, he'll have no doubt thought of such a scheme before. :P
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

Twilighte wrote:We do have some very fast line drawing routines now. And i have somewhere a fast circle drawing routine (note circle and not ellipse).
Any figures about this? I have made some tests and found that most probably that will be the bottleneck. I have a routine (a modified Bresenham) which takes over 30000 cycles to draw a complete diagonal in the Hires screen (that is over 32 diagonals per second). It is a general routine which takes two screen coordinates and draws the line.

I also have a fast multiplication routine, but limited to 8bit signed numbers in the range (-127,127) which I'm afraid would not be enough.

Would be interesting to have a repository of all these functions and compare them in memory waste (I know about a fast 9-bit multiply routine, but uses 4K tables!) and speed.

I am using a trick for projections to avoid divisions and just make multiplications, but I think I will have to move to 16-bit multiplication, which will be a problem. Need some tests for this...

[\quote]
As Dbug has said before, the major problem is that the Oric has no ability to screen switch.
...

I think the spectrums Screen can be banked to another part of memory, which facilitates 3D graphics alot. Also the Z80 even at 3.5mhz zips along alot faster than other 8 bit micros.

[/quote]

Well the speccy did not have screen banking. Some games (Fairlight IIRC) used double-buffer and the LDIR z80 instruction to copy the buffer into the screen, but that is a HUGE waste of memory and will be slow in Oric (?). Blanking the screen by blocks or, as I said, using eor to draw pixels, so drawing a line twice ereases it, might work.

It might flicker, though, if not in sync with screen, but worth a try...

The problem with the 6502 is it is slower in number crunching than the z80. I think the 6-pixels per scan is not going to be a real problem in this kind of games. My pixel_address routine is quite fast, and I use a modified faster version for finding the address and bit in scan for adjacent pixels.
It is possible to set up two switchable screens on the Oric but of limited vertical and horizontal resolutions.
[...]
This is indeed very interesting, but I really hate to limit the screen resolution.

I think the worst problem here will be the math and line drawing. We should use 16-bit signed number.

As soon as I have some time, most probably next week, (and after working a bit on Wurlde so Twilighte does not kill me) I might try something...

Cheers.
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

Chema wrote:
Twilighte wrote:We do have some very fast line drawing routines now. And i have somewhere a fast circle drawing routine (note circle and not ellipse).
Any figures about this? I have made some tests and found that most probably that will be the bottleneck. I have a routine (a modified Bresenham) which takes over 30000 cycles to draw a complete diagonal in the Hires screen (that is over 32 diagonals per second). It is a general routine which takes two screen coordinates and draws the line.
Indeed a good drawing routine is critical. And the erasing/update is critical as well. Also what is important is to find out if clipping is necessary or not. Clipping can easily kill the performance of a routine.

Diagonals is not a very good test case because it's the longest possible line, which tend to improve the performance of routines which have a small cost per pixel but a longer setup time.

Could you insert your line drawing routine in the bench I wrote some years ago (when I working on ULA paint), right now there is only mine and the default basic routine, with your and Twilighte ones this could start to be interesting, and then from there other people can contribute.

http://www.defence-force.org/ftp/forum/ ... eBench.zip

Can probably improve/add test cases to test the routines in various situations: Long lines, small lines, clipped lines, etc...

Also here I erase in XOR mode, which obviously if you plan to erase everything is not necessary: Just erase the whole byte.

Chema wrote: I also have a fast multiplication routine, but limited to 8bit signed numbers in the range (-127,127) which I'm afraid would not be enough.

Would be interesting to have a repository of all these functions and compare them in memory waste (I know about a fast 9-bit multiply routine, but uses 4K tables!) and speed.
Sure, just put your own code on the ftp, like for example here:
http://www.defence-force.org/ftp/forum/code_repo/maths/

Of course the topic is open to everybody, so if you can contribute with source code, optimisations, or just smart remarks, you are all welcome :)
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

Ok I surrender :)

Your routine is nearly twice faster than mine Dbug... which is quite impressive. 864 1/100th of a second against 1768. In my calculations it should have been over 1320, but I had to add some extra code. Anyway the difference is quite big!

The cost is space. If I calculated it correctly you are using 711 bytes and I am using just 313. That is because yours has special cases to enhance performance... and, as I saw, many other tricks!

I did not align anything to page boundaries for example.

For 3D we must have a fast line draw, so I think we can cope with the cost of space... we allways have overlay!

I am not sure about your pixel_address, but I suppose it is not HUGE!

Well now we need some fast math and see the precision we need (more than 8-bit for sure, probably 16).

Fast routines for multiplication division with 16-bit ?
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

Actually I'm not sure that the timing thing is really correct.
I used a stop watch to count the time spent to draw, and the 864 is actually 10 seconds. Should have been 8.6 seconds...

Then I modified the code to draw 1000 diagonals from top left to bottom right, and it took 29 seconds, which is about 34 lines/second.

Something to consider as well is that we are losing about 20% of the whole cpu time due to the crapy IRQ system, which is easy to rewrite for a game purpose.

I seriously doubt my code is twice faster as yours, mostly because mine is just a brensenham with a variant for >45° and <45° slopes values.
User avatar
Twilighte
Game master
Posts: 819
Joined: Sat Jan 07, 2006 12:07 am
Location: Luton, UK
Contact:

Post by Twilighte »

One interesting idea, and again unsure if it has already been suggested is that when the line is drawn, each bitpos and screen location is stored back to a list. Then just recall the list with Chema's EOR idea to erase the line.

I believe the line drawing routine i had is the same one as Dbug currently has. Sorry.
Post Reply