ZDoom

2008 laptop here also with an Intel chipset. Made even worse by the fact it's a GLE960, pretty much the laptop equivalent of the G41 "complete and utter garbage" chipset (which I used to have, too). Actually, it can barely even run GZDoom at all.

So yeah, unless we're talking dedicated GPUs or "modern" integrated ones, that's not true at all.

Nash wrote:With the eventual implementation of GL skyboxes, models and flat sprites - plus dynamic lights properly lighting sprites (it currently does not, I understand this is WIP) - it WILL pretty much be GZDoom for ghetto computers.

If you're the kind of people who don't mind switching from "frames per second" to "seconds per frame", then yes, you will be able to use QZDoom to get the full experience of dozens of dynamic lights at once on a ghetto computer.

Such computers will render SPF in OpenGL anyway - so that really doesn't matter.

And I suppose fancy things like Bloom, Tone Mapping and SSAO will also get in the software renderer, right?

If you need help with that pls give me a call.

MarisaKirisame wrote:And I suppose fancy things like Bloom, Tone Mapping and SSAO will also get in the software renderer, right?

It depends. On a Gitbuild there was Dynamic Lights on software renderer so, aside from all that, real 3D models on software is the last i'm expecting.

Let's put a palette tonemap on the 32-bit software renderer

Gez wrote:Let's put a palette tonemap on the 32-bit software renderer

I've actually wanted to do that.

Yes, I know it sounds insane. No I don't care how insane that sounds, I still want to do it.

Hmm, the models could be a flat Sprite, that's converted from polygons to a Sprite each frame.
You just need something to draw a Sprite into a buffer, get the position from the player câmera and the model and "take a Picture" from that angle, store the resulted buffer into a Sprite and "reuse" the same Sprite render code that's used to render the sprites.

If I remember right the triangle drawer is already there, So, it just need another tool to convert MD3/MD2 stuff to triangles? (ehm, just take the existing code from gzdoom, since a gpu doesn't know what a md2/md3 is but they know what triangle are)...

wish I could talk less and code more, but I have almost zero experience with the 3D scene (I still can't imagine that I did a medical software for viewing/editing 3d models O_o [ofc using vtk so 99% of all 3D stuff was already done])

EDIT:
Will Qzdoom support subtract dynamic lights in software render?
so I could use my raytracing engine into it

Question with the latest QZDoom version: Why is xBRZ gone from the HQ Resize modes?

Ask the menu code.

It's there - and it's even there in the menu defs. But for whatever reason, the menu code is not seeing it.

The CVAR is gl_texture_hqresize, and here are the valid values:

Code: Select all • Expand view

OptionValue "HqResizeModes"
{
   0, "$OPTVAL_OFF"
   1, "$OPTVAL_SCALE2X"
   2, "$OPTVAL_SCALE3X"
   3, "$OPTVAL_SCALE4X"
   4, "$OPTVAL_HQ2X"
   5, "$OPTVAL_HQ3X"
   6, "$OPTVAL_HQ4X"
   7, "$OPTVAL_HQ2XMMX"
   8, "$OPTVAL_HQ3XMMX"
   9, "$OPTVAL_HQ4XMMX"
   10, "xBRZ 2x"
   11, "xBRZ 3x"
   12, "xBRZ 4x"
   13, "xBRZ_old 2x"
   14, "xBRZ_old 3x"
   15, "xBRZ_old 4x"
}


ibm5155 wrote:Will Qzdoom support subtract dynamic lights in software render?

Probably not at this time. While they are theoretically easy to add (just do what AddLight already does in the drawers, but replace the + with -), the speed impact is going to get too big.

I mostly added the dynlights out of curiosity because I wondered exactly what the speed would be. It is much better than I feared it could be, but not good enough to fully support all of it.

ibm5155 wrote:so I could use my raytracing engine into it

I know that must've taken quite a lot of effort and I can appreciate it, and don't mean to put your work down but - I fail to see the ultimate point and end-goal of that, when a far better, less-hacky and much more performance-friendly thing to do is write a true real-time cascading shadow mapper... IDK, abusing subtractive lights (which are expensive to draw already, even in small quantities) just sounds masochistic...

Well as long as you're having fun though, it's all cool!

Well no matter how it's done - I gotta say that video demonstration is pretty damn cool. Yes, I know running it will simultaneously murder my CPU and GPU and send my poor little laptop to an early grave.

Nash is right that it needs to ultimately be implemented a little bit differently - but I gotta admit, I love the way ibm5155 is curious and likes to tinker with things like that. That kind of thing is very innovative and creative and it opens up a whole world of possibilities.

Unfortunately, though - that little demonstration will not run with acceptable performance on QZDoom's software renderer whatsoever - sorry to say. And I can tell you that without even trying it - because it takes a lot of processing power just to even know which lights to show where, least of all how far a pixel is away from any number of nearby lights. This is compounded by the fact that both operations - the rendering and the casting for the lights - will be CPU-choked. You'll be lucky to get 5-10 frames per second out of that even with a modern processor.

As I've said before - "cool to have" sometimes just isn't "practical."

Less-hacky thing is actually make limited radius light that creates smaller dynlights WHERE IT HITS as opposed to creating negative dynlights where it doesn't. IMO.
Plus if distance is limited, you can do a bit higher precision, I believe.

One thing that is feasible is making a wireframe grid on the level geometry - both on the flats and on the walls - where at each intersection of the grid its point is measured by distance from the dynamic light as well as whether it can see the dynamic light. Then you can apply gouraud shading to those points, using gradient transitions for all the tween pixels. But that would be done without using so many dynlight objects, obviously.

It wouldn't look great, but at least it would run acceptably.