Wolfenstein / DOOM for Oric : has this been done?

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

Re: Wolfenstein / DOOM for Oric : has this been done?

Post by Dbug »

NekoNoNiaow wrote: Sat Mar 31, 2018 6:51 amAIC would imply HIRES right?
There are so many ways to answer this seemingly simple question :)

At the core, yes AIC implies HIRES.

That being said, if you are willing to have your brain melt, there are plenty of screen combinations you can achieve, including alternating between HIRES and TEXT every scanlines, so technically you could draw the walls in HIRES and the sprites in TEXT, or the opposite, or you could just use the TEXT to draw the floor and ceiling part, etc...

So basically you can have independent colors for paper and ink for each of the 8 sub-scanlines even in TEXT mode (that's how I do my rotozoms and tunnels with many dithered colors), so that's most of the AIC working there: Just design your characters to have texels hit the odd or even scanlines to get the right colors. The one thing that does not work well though is the inverse part: It's all or nothing at the character level.
User avatar
NekoNoNiaow
Flight Lieutenant
Posts: 272
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

Re: Wolfenstein / DOOM for Oric : has this been done?

Post by NekoNoNiaow »

Dbug wrote: Wed Mar 28, 2018 5:57 pm I did an attempt around 2001:
walls.zip

It did not go very far because I did not manage to find a satisfactory way to avoid the fish eye effect, as well as how to get some decent looking walls with shading effect that don't cost too much cpu time.
I have not yet looked at the source but I decompressed it on my disk so I am almost there :D and hope to give it a look this week end!

I also stumbled on one of ThomH's video on his YouTube channel tonight which shows a VIC-20 game which very much resembles Midi Maze (an Atari ST game playable in network using MIDI cables) and could be using a raycasting engine. It might of course be using a different technique since it does not use any textures but nevertheless its drawing speed is quite impressive, especially given that there are two points of view computed and displayed on the same screen.



My intuition is that the VIC-20 "bitmap" mode (it is not really bitmap but it kinda can be used as one) might be either equally or more demanding in terms of bandwidth than the Oric's HIRES so this probably is a good benchmark of what could be achieved on the Oric.

And in passing, my, this game is from 1983! Carmack was beaten by almost a decade! ;)
ThomH
Flying Officer
Posts: 238
Joined: Thu Oct 13, 2016 9:55 pm

Re: Wolfenstein / DOOM for Oric : has this been done?

Post by ThomH »

Here's a longer video of the same title by somebody other than me, not implicitly about proving that they've fixed a counter placement bug:


It was also available with completely different graphics for the Atari 400/800/etc, with the faster processors:


... and is the two-player sequel to a 1982 original:


Those trivia facts aside, my main observation about the Vic-20 version was that there is a constant vertical black edge scaling with the wall as it intersects the left edge of the display, and the opponent if you ever meet is rendered as a rectangle of exactly wall height. So it might be forward rendered rather than backward, but having posited that as a smart way to code earlier in the thread I might be suffering from confirmation bias. But it would seem to suggest that the struts between walls are placed by having some sort of overview of the whole segment, wouldn't it?
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Wolfenstein / DOOM for Oric : has this been done?

Post by Dbug »

I wonder if the source code for these games have been released, but yeah, definitely impressive!

They probably only draw one half and use mirroring?
User avatar
NekoNoNiaow
Flight Lieutenant
Posts: 272
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

Re: Wolfenstein / DOOM for Oric : has this been done?

Post by NekoNoNiaow »

ThomH wrote: Wed May 09, 2018 3:02 pm Here's a longer video of the same title by somebody other than me, not implicitly about proving that they've fixed a counter placement bug:
[snip]

It was also available with completely different graphics for the Atari 400/800/etc, with the faster processors:
[snip]

... and is the two-player sequel to a 1982 original:
[snip]
The 1982 original is Impressive indeed, the frame update time is probably above 3 VBLs (i.e., less than 16.7-20 FPS) but the frame rate is quite steady and smooth enough for reactive gameplay.
I wonder how come this game is never listed as the precursor to Hovertank 3D and Wolfenstein 3D? It precedes the former by almost a decade.

With all the horizontal wasted screen estate of that first version though I can understand why the author went for a dual view for the next one, although I would have probably also increased the horizontal field of view for the single player version so as to reinforce the immersion. Had he done that he would probably also have deserved the title of first wide screen game ever. ;)
ThomH wrote: Wed May 09, 2018 3:02 pm Those trivia facts aside, my main observation about the Vic-20 version was that there is a constant vertical black edge scaling with the wall as it intersects the left edge of the display, and the opponent if you ever meet is rendered as a rectangle of exactly wall height. So it might be forward rendered rather than backward, but having posited that as a smart way to code earlier in the thread I might be suffering from confirmation bias. But it would seem to suggest that the struts between walls are placed by having some sort of overview of the whole segment, wouldn't it?
It seems possible that the black vertical edge could be present too with a backward renderer but I agree that a forward renderer would make more sense as (as I understand it) it eliminates overdraw, which is a welcome feature for these CPU cycles starved machines.
(Note that on the original 1982 version on the Atari 800, the black edge is on the right side of the screen!)

I also agree that it would likely be more efficient to render the struts on top of the walls since this would allow a large part of the drawing of the walls to be done by filling large solid rectangles instead of column by column. This would allow to draw a large surface area using a very fast block filling routine. The remaining parts would then be drawn column by column, followed by the struts added on top of everything as a final pass.

If this does not make sense you can refer to this image which illustrates which areas can be drawn using a very fast block filling routine (denoted "FAST"):
WallFilling.png
This said, this is pure conjecture, maybe all columns are drawn one by one. One would need to disassemble the game to verify.

Note that the game is likely faster on the Atari because the rendering area uses a 4 colors screen mode: the sky gradient and the ground are probably the same color coupled with a display list to change the palette every few lines. I suspect the screen mode used for the 3D section is ANTIC D, which is a 160x96 pixels mode with 4 colors (cf https://www.atariarchives.org/agagd/chapter1.php but be warned that the Atari 8 bit screen modes are an absolute nightmare, even the Oric is simpler :D).
Dbug wrote: Wed May 09, 2018 7:17 pm I wonder if the source code for these games have been released, but yeah, definitely impressive!
From Wikipedia (https://en.wikipedia.org/wiki/Capture_t ... ideo_game)) and AtariMania (http://www.atarimania.com/game-atari-40 ... g_888.html) it does not look like the source is available. A naive web search did not return anything useful either alas.
Dbug wrote: Wed May 09, 2018 7:17 pm They probably only draw one half and use mirroring?
This seems likely indeed since it is a very simple optimization to add.
Note that on the Atari 8 bit they could even avoid to mirror-copy the bottom of the screen since it is possible to reuse the lines already drawn for the top of the screen by generating an inverted display list which resets the bitmap address to fetch data from back to previously drawn lines.

I am almost tempted to search if there is an Atari 8 bit emulator which allows to live-dump the content of the display lists. ;)
User avatar
jbperin
Flight Lieutenant
Posts: 480
Joined: Wed Nov 06, 2019 11:00 am
Location: Valence, France

Re: Wolfenstein / DOOM for Oric : has this been done?

Post by jbperin »

With permission of DBug

I've started to rework the prototype he'd posted here.


Here's where it has led :
rewall00.gif
rewall00.gif (309.07 KiB) Viewed 6804 times
rewall00.tap
(6.99 KiB) Downloaded 211 times
I've pushed the source code here.


Despite I have some appealing ideas on how I could push this prototype a bit further (because it is terribly smart and I know how to enhance on the aesthetic and performance level), I pause my works on this demo because I need to explore a new approach I thought of recently and which is obsessing me since I had the idea.

Chema wrote: Sat Aug 29, 2020 6:41 pm A bit off topic, I know, but has anyone ever played with raycasting on an Oric? I have the feeling that it is way beyond its capabilities, but who knows...

I mean having something faster than 1 fps on, say, 1/2 the hires area..
I don't know if what I recently discovered will make it possible to do RayCasting on an Oric, but I know for sure that it could change the way we can imagine the answer.

I started by using math to answer the question:

How do I compute the distance between the camera and the point of intersection between a wall and a ray I would cast from the camera toward the wall ?
RayCastMath.png
User avatar
jbperin
Flight Lieutenant
Posts: 480
Joined: Wed Nov 06, 2019 11:00 am
Location: Valence, France

Re: Wolfenstein / DOOM for Oric : has this been done?

Post by jbperin »

As shown above, I felt on a big ratio to compute; full of heavy cos, sin, multiplication and division.

Facing the denominator sin(alpha).cos(beta) - cos(alpha).sin(beta), I thought I was lost.
But I decided to keep on struggling .. not fearing the size of the monster boss I had to defeat.

I started drawing my enemy to better figure what it was looking like:

Surface.PNG
And, then .. like if god was guiding my hand to victory as I was about to silently die in a dark and forgotten cave, I felt on the following angle of view :
Curve.PNG
WWWAAAAAoooOOOOuuuuUUUU !!!!

THE CURVE IS SYMMETRIC ALONG THE BETA=-ALPHA AXIS !!!!

I CAN'T BELIEVE !!!

LET'S OPEN A BOTTLE OF CHAMPAIN !!


I immediately felt that I had found something incredible and that, with this discover, I could make jaws of Chema, DBug, Iss and TomH fall.

Because the very big divisor was suddenly becoming hyper slim !!!
Just a simple one-dimension lookup table !!!! Can you believe that ??

So I immediately started coding the stuff.
I used logarithmic division to do the ratio, made a smart exponential to revert it and then now I can proudly announce that I have a RayCast function that can compute a ray cast distance in about 1000 cycles !!

YES MEN .. YOU READ RIGHT !! 1000 cycles !!

And for those who still can't feel amazed by this perspective, I announce that I'm working on a booster that is expected to make the raycast function compute the distance to the wall in less than 500 cycles !!!

I know that it is not a Doom nor a Wolfeinstein .. but that's a core component for those wanting to make a Midi Maze - Like game ..
User avatar
kenneth
Squad Leader
Posts: 514
Joined: Fri Nov 26, 2010 9:11 pm
Location: France PdD
Contact:

Re: Wolfenstein / DOOM for Oric : has this been done?

Post by kenneth »

Congratulations !
I like the "real 3D" maze :shock: :shock: 8)
User avatar
ibisum
Wing Commander
Posts: 1643
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Wolfenstein / DOOM for Oric : has this been done?

Post by ibisum »

I hope I can understand this fully one day. ;)
User avatar
Symoon
Archivist
Posts: 2301
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France

Re: Wolfenstein / DOOM for Oric : has this been done?

Post by Symoon »

Same as Ibisum, this is way beyond what's left of my mathematics level.
But there are two things that this gives me hope for:
1- drinking Champagne
2- seeing Mercenary on Oric some day ;)
User avatar
kenneth
Squad Leader
Posts: 514
Joined: Fri Nov 26, 2010 9:11 pm
Location: France PdD
Contact:

Re: Wolfenstein / DOOM for Oric : has this been done?

Post by kenneth »

I didn t know the Mercenary videogame I saw some videos, that make me want...
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Wolfenstein / DOOM for Oric : has this been done?

Post by Dbug »

Assuming Jibé manages to get all that stuff together, now that we have the 8-bit hub that gives network access, it would be technically possible to do something like Midi Maze on the Oric.

User avatar
ibisum
Wing Commander
Posts: 1643
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Wolfenstein / DOOM for Oric : has this been done?

Post by ibisum »

Wicked idea. Maybe even a SpectreVR, also!

User avatar
rax
Flying Officer
Posts: 193
Joined: Tue Jul 24, 2018 3:16 pm

Re: Wolfenstein / DOOM for Oric : has this been done?

Post by rax »

Congratulations jbperin !!!

The versions I have seen for ZX Spectrum and Commadore, they do not occupy the entire screen but only the top or sometimes they also have a border on the side. Perhaps this will make it easier to draw the buffer and improve speed.

Good job! Keep me a key here too :)
User avatar
jbperin
Flight Lieutenant
Posts: 480
Joined: Wed Nov 06, 2019 11:00 am
Location: Valence, France

Re: Wolfenstein / DOOM for Oric : has this been done?

Post by jbperin »

Hi all,

I've been exploring the subject of brut force ray casting on Oric and, surprisingly, I think I found a way to reach a satisfying level of performance with this approach.
I say "brut force" because the principle is to :
- scan ALL walls of a scene for they part in the field of view,
- compute the distance to the camera for each ray angle in the field of view
- keep a z-buffer with closest distance found to determine which wall is visible on which part of the screen.

To afford such a brutal approach,I first restricted the study to cases with only aligned wall. As in Wolfeinstein, walls can only be aligned with (O,y) or (O,x) axis.
This led to important simplifications in the distance calculation.

It turned out that distance is either:
- (Xcamera-Xwall)/sin(alpha) for (O,y) aligned walls or
- (Ycamera-Ywall)/cos(alpha) for (O,x) aligned walls

In order to avoid the division, I do all computation in logarithmic scale.
For a given wall,I first compute the numerator log2(32*(Xc-Xw)) or log2(32*(yc-yw)) depending on orientation of the wall.
Next, for each ray angle alpha, i pick the denominator in a precalculated look-up table containing log2(32*(1/sin(alpha)) or log2(32*(1/cos(alpha)).
thus, the distance calculation is only one 16 bits addition+ an indirect indexing + one 16 bits comparison to deal with z-buffering. And that's all.
One i have computed the logaritmic z-buffer, I apply the anti fisheye transformation on the result before I exponentiate the whole with a precalculated look-up table .

For better performance, I use the exponentiation look-up table to also performs the Distance to Height transformation.

I can't see how there could be faster way to proceed.

You have to know that in the .tap here, only the rendering part and the arctangent operator are in assembly language .. all the rest is in C language.
So there remains lots of cycle to save that could be used to enhance the rendering and/or add some gameplay.
oricast.tap
(20.82 KiB) Downloaded 174 times
Post Reply