А ведь двустволку в 3DO DooM хорошо было бы прикрутить

а что aliast не может это сделать?

I have started working on this port again, this time adding some new features I had in mind for a long. 3DO does have a feedback texture function, where you can render something in an offscreen buffer and then read a region of it back like a texture, interpreted with the non linear videoram data structure of 3DO. This is pretty fast on the CEL, no overhead noticed.

So, I thought why not use this to limit the rendering to half Width or half Height or both, instead of the hacky way I was skipping half columns during one part of the column rendering (but didn't do the same for the visplane creation that goes through the wall columns once again, because of uncontrolled visplane spills), I can much easier and a bit faster do the same just be rendering the window with half width or height in the offscreen buffer, then reading the screen region as a texture (using flags PRE1_LRFORM) and scale it back to normal.

I could also add the additional functionality to scale it up to fit the screen, so now you can switch to the smallest screen size, then fit that back to screen to get something that looks like you ran Doom on AtariVCS or something :)
Enable the gimmicky wireframe option and it also looks like you run it on a graph calculator =)

Of course these blocky cases are too low to enjoy Doom, but with a bit higher screen sizes, maybe a bit tweaking of the scalers, one can get a little bit more framerate (but unfortunately it's not as satisfactory in the very demanding views).

This is 1/3rd of the primary things I want to add before releasing v0.2b. I named it 0.2b because there are some more serious and time consuming things (mainly trying to replace floor/ceiling rendering with a method that will not use the visplanes but actual polygons, this needs a lot of work and research in various places, like storing tessalated polygons of sectors in the BSP data or somewhere, projecting them, figuring out what to do without texture coords, etc) and I wanted to release a smaller version before moving to 0.3.

So, I thought why not use this to limit the rendering to half Width or half Height or both, instead of the hacky way I was skipping half columns during one part of the column rendering (but didn't do the same for the visplane creation that goes through the wall columns once again, because of uncontrolled visplane spills), I can much easier and a bit faster do the same just be rendering the window with half width or height in the offscreen buffer, then reading the screen region as a texture (using flags PRE1_LRFORM) and scale it back to normal.

I could also add the additional functionality to scale it up to fit the screen, so now you can switch to the smallest screen size, then fit that back to screen to get something that looks like you ran Doom on AtariVCS or something :)
Enable the gimmicky wireframe option and it also looks like you run it on a graph calculator =)

Of course these blocky cases are too low to enjoy Doom, but with a bit higher screen sizes, maybe a bit tweaking of the scalers, one can get a little bit more framerate (but unfortunately it's not as satisfactory in the very demanding views).

лол

It's time to start another category of OptiCode that will focus on simple coding tutorials. Instead of working on some new thing, I'll code something basic from scratch to show you how it works. I'll start with simple 3DO coding tutorials for the next few videos.

This one is using my framework on the tutorial page https://3dodev.com/tutorials/optimus_3d ... _tutorials and starts as a base, and then showing how easy it is to create a CEL, move position, scale and rotate, then finally creating many objects of it and teach how it's better to link the CELs together and only call DrawCels once for the best performance. It's a very basic primer on CEL rendering, and totally doesn't touch the 99% of the complexity of all these special flags and bits which I'll leave for future tutorials.