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 ..
Wolfenstein / DOOM for Oric : has this been done?
Re: Wolfenstein / DOOM for Oric : has this been done?
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.
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.
Re: Wolfenstein / DOOM for Oric : has this been done?
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.
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.
Re: Wolfenstein / DOOM for Oric : has this been done?
Code: Select all
If you have python and PIL library installed, you can rebuild all generated files before rebuilding the tap file.
Re: Wolfenstein / DOOM for Oric : has this been done?
You're totally right. And I realise that the library is now called Pillow rather than PIL.
https://pypi.org/project/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.
https://pypi.org/project/Pillow/
Code: Select all
pip install pillow
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.
Re: Wolfenstein / DOOM for Oric : has this been done?
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 ?
Re: Wolfenstein / DOOM for Oric : has this been done?
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.
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.
Re: Wolfenstein / DOOM for Oric : has this been done?
Is there something wrong with PictConv -o3 and -o4 modes?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.
-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.
Re: Wolfenstein / DOOM for Oric : has this been done?
Perhaps I don't know the right parameter. When I run this command on the 32x32 pixels texture :
I obtain this:
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 ?
Code: Select all
castoric>%OSDK%\Bin\PictConv.exe -o2 -o3tabtext img\bluestone.png fic.h
Code: Select all
unsigned char tabtext[192]=
{
0x40,0x40,0x40,0x40,0x40,....,0x40,0x40,0x40,0x40,0x40
};
https://github.com/oric-software/castor ... luestone.h
Is there something I do wrong ?
Re: Wolfenstein / DOOM for Oric : has this been done?
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?
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?
Re: Wolfenstein / DOOM for Oric : has this been done?
I will try to try it as soon as possiblejbperin 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.
You have a good documentation. I will be interesting to try it.
Re: Wolfenstein / DOOM for Oric : has this been done?
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.
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
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.
Re: Wolfenstein / DOOM for Oric : has this been done?
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.