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
ibisum
Wing Commander
Posts: 1645
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

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

Post by ibisum »

jbperin wrote: Tue Feb 16, 2021 8:45 pm I will soon release source code, design tools and some usage doc.

Very exciting! Can't wait to see what sort of craziness ensues .. also, I wonder if this would be usable for a flight sim, 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 »

ibisum wrote: Tue Feb 16, 2021 10:33 pm I wonder if this would be usable for a flight sim, too ..
Raycasting is not the most appropriate technology to create a flight sim. Lib3d used in 1337 is the most adapted tool to create a flight sim beause it has roll angle.
rax wrote: Tue Feb 16, 2021 8:47 pm So cool :)
Congratulations !
We are waiting :)
I pushed source code and some doc in the following repository: https://github.com/oric-software/castoric/

It's a WIP so it is neither clean nor optimized.

If you have any idea of what could be cool to change or add to make oric developpers interested by this technology. Let me know.
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 »

I forgot to say:

Walls can't be longer than 24 units and must be either (O,y) aligned or (O,x) aligned (i.e their extremities point share either the same X or the same Y coordinate).

For longer walls, one have to create several walls one beside the other and sharing a common junction point.

There's a maximum number of points and walls defined somewhere.
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

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

Post by Dbug »

Code: Select all

If you have python and PIL library installed, you can rebuild all generated files before rebuilding the tap file.
Maybe indicate somewhere which version of Python it requires, and how to install PIL?
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 »

You're totally right. And I realise that the library is now called Pillow rather than PIL.

https://pypi.org/project/Pillow/

Code: Select all

pip install pillow
I recommend last version of Python (3.9) but it should work from Python 3.7 or 3.8.

I am having a very limited access to internet at the moment so I can't update the repo right now.

It is possible to create exe file from Python script. It could ease the process. Even though the best solution would be that pictoric outputs the buffer so that the only dependency would be OSDK.
User avatar
Magoric
Officer Cadet
Posts: 36
Joined: Sun Sep 27, 2020 8:23 pm

Re: Full Hires Screen Color Textured Raycasting on Oric

Post by Magoric »

jbperin wrote: Tue Feb 16, 2021 12:24 pm
video00.gif

Wow!! It is great! Very, very good work!
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 »

Magoric wrote: Sat Feb 20, 2021 3:17 pm Wow!! It is great! Very, very good work!
Thank you very much Magoric. I'm glad to hear that you appreciate my work :-)
sam
Officer Cadet
Posts: 57
Joined: Sun Jul 09, 2017 3:28 pm
Location: Brest (France)
Contact:

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

Post by sam »

jbperin wrote: Sat Feb 20, 2021 1:48 pm Even though the best solution would be that pictoric outputs the buffer so that the only dependency would be OSDK.
Did you mention PictOric ? I don't see exactly what you mean by "the buffer". Can you elaborate a bit more on that topic for me to understand what is needed ?
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 »

Oups .. I may have confused with PictConv

I was thinking of a tool delivered with OSDK which generates C or asm buffer from image file.
And I don't know why I thought it was PictOric.

The goal is to transform image texture file from this directory (which are simply 32x32 pixels) into buffers such as this one for them to be usable by the the raycasting engine.

It is currently done by the python script texture2buf.py but it implies a dependency to the the Pillow library.

I was thinking at a replacement of this script by a tools that Oricians already have on their computer.

The principle of colour encoding is described here.
User avatar
Dbug
Site Admin
Posts: 4444
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 was thinking of a tool delivered with OSDK which generates C or asm buffer from image file.
And I don't know why I thought it was PictOric.

The goal is to transform image texture file from this directory (which are simply 32x32 pixels) into buffers such as this one for them to be usable by the the raycasting engine.
Is there something wrong with PictConv -o3 and -o4 modes?
-o3[label name] => C source code
-o4[label name] => assembler source code

https://osdk.org/index.php?page=documen ... e=pictconv

I think you managed to confuse both the PictOric and PictConv creators, because I'm not sure about which tool is missing what.
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 »

Perhaps I don't know the right parameter. When I run this command on the 32x32 pixels texture :
Image

Code: Select all

castoric>%OSDK%\Bin\PictConv.exe -o2 -o3tabtext img\bluestone.png fic.h
I obtain this:

Code: Select all

unsigned char tabtext[192]=
{
	0x40,0x40,0x40,0x40,0x40,....,0x40,0x40,0x40,0x40,0x40
};
there are 192 bytes .. all same value .. rather than a 1024 bytes (=32*32) array like this one:
https://github.com/oric-software/castor ... luestone.h

Is there something I do wrong ?
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

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

Post by Dbug »

Ha, yes of course, you want one byte per pixel, it's not specifically Oric format.
Yeah, that's not supported, I missed that, there's Bin2Txt in the OSDK to export text files, but there's no simple pixel to byte converter, which brings the interesting question of how the heck did I do my rotozoomer bitmaps Oo

After a bit of investigation, I find out that I just exported the image from PSP to raw 256 colors format, and then ran Bin2Txt on the result, but yeah, I guess a proper converter would make sense, the question being how to interpret the values, because I can see multiple use case:
- Just something to export in values from 16+0 to 16+7 to draw a zoomed out picture with just paper attributes
- Something to convert RGB colors using my 64 color mode with dithering characters
- Other?
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 »

jbperin wrote: Fri Feb 19, 2021 3:46 pm
I pushed source code and some doc in the following repository: https://github.com/oric-software/castoric/

It's a WIP so it is neither clean nor optimized.

If you have any idea of what could be cool to change or add to make oric developpers interested by this technology. Let me know.
I will try to try it as soon as possible :)
You have a good documentation. I will be interesting to try it.
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 »

Dbug wrote: Sun Feb 21, 2021 12:29 pm - Other?
For castoric, I use the 6 least significant bits of a byte to encode the color of a pixel (in texture) /texel (on screen).
The 6 bits are composed of three groups of 2 bits for each Red, Green and Blue components.
rax wrote: Mon Feb 22, 2021 12:06 pm I will try to try it as soon as possible :)
It's cool :-)
I've just pushed some optims and there are some more optim to come.

I've allmost finished to optimise the render part. I'll try to have this part reviewed by _Dbug_ to see if never he sees some optims that I have missed.

Now I'm working on optimising the calculation. The calculation is what happens between the moment we press a key and the moment the image starts drawing. There remain some significant optim to do on this part.

These optim won't impact the way the system work.
The only thing that I plan to do and that will change the way to use the system is the clearing of the viewport.

For now it is done, in the gameloop, with a :

Code: Select all

        memset(HIRES_SCREEN_ADDRESS, 64, 8000);
        prepareRGB(); // Reinstall CHANGE_COLOR attributes at the beginning of each scanline
Which is terrible in term of performance. So I really need to make a neat function that clears only the viewport and that runs fast as hell.

Thus, the 2 things that are unstable and going to change in a near futur are:
- clearing the viewport in a more efficient way,
- make processPoints and processWalls compute faster.
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 »

jbperin wrote: Mon Feb 22, 2021 5:26 pm - clearing the viewport in a more efficient way,
Done !! :-)

Fast viewport clearing give the impression that the whole stuff goes faster.

I've just tested on a 40*40 texels viewport and I find it reacts smoothly.

There's still a sweep effect when scene draws (and I think I can't avoid it as long i use a direct to screen rendering method).
But there's enough to provide the gamer with a nice immersive experience.

It's a bit frustrating that it is not as fast as the rayasting of Lawless Legends on Apple II :

It is also slower that the raycasting on TI-99 :
But I supect the guy from the TI-99 demo to use a GPU F18A for the rendering to be so fast.
Post Reply