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: 2664
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

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

Post by Dbug » Sat Mar 31, 2018 7:25 am

NekoNoNiaow wrote:
Sat Mar 31, 2018 6:51 am
AIC 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
Pilot Officer
Posts: 116
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

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

Post by NekoNoNiaow » Wed May 09, 2018 6:05 am

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: 146
Joined: Thu Oct 13, 2016 9:55 pm

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

Post by ThomH » 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:


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: 2664
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

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

Post by Dbug » Wed May 09, 2018 7:17 pm

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
Pilot Officer
Posts: 116
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

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

Post by NekoNoNiaow » Thu May 10, 2018 5:08 am

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. ;)

Post Reply