I have recently, and will be for several months, been switching to a Pentium 4 Toshiba laptop with Windows XP Home SP3.

The problem is that, no custom engine i have tried (Aguirre's Enhanced GLquake, Quakespasm, ReQuiem, Fitz, Fitz Mark V ...) runs at all or runs even close to a decently speed in this computer, even before loading a map, i don't know if because of the age of the computer, compability reasons, or bugs (this last case probably not as i have tested in several engines). In case of Fitz and Aguirre's the video fails but the rest works, in the first engine the screen is black and in the second the console doesn't drop and everything is in a low color mode. Fitz Mark V won't even load. DirectQ gives me the same error as in almost any computer till now.

So far only WinQuake that comes with Aguirre's GL engine works (haven't tested the original one to see if its different). And thanks to this i am noticing how much we are depending on the added engines features, as my maps look so different now without them.

All the info i get from the engines besides Fitz, Fitz MArk V and AGuirre's is several warning messages about non-supporting several features or not finding certain things, the newer the version engine the more the warnings.

So the question is, which engine would be able to run well besides WinQuake, or what can i turn down in any engine (i use mostly Quakespasm)so it works good enough to play? 

Because of my work I use the NumPad a lot. So far only QuakeSpasm seems to allow typing in the console with it. An engine that has individual transparency for each liquid would also be welcome. 

More than likely the laptop's hardware is lacking, the video in particular. I ran Fitzquake on XP for years, but that computer had a pretty decent Nvidia video card. 

I remember Aguirre's engine and old versions of Fitz ran perfectly on much older rigs back then. 

What's your gpu? Got drivers installed? Try r_dynamic 0. 

Is a sure sign of windows software rendering, caused by missing or not-working graphics drivers.

gl_info in the quake console will print info on the driver being used, to confirm this

If you dont know the exact gpu model in that laptop, try the utility "GPUZ" which should tell you 

If you can use winquake, then try qbism's Super 8 engine. It is a software engine like winquake but supports lots of the new features. 

With a Pentium 4 and from how you describe it, you've almost certainly got an old Intel graphics chip. The age of the CPU is unfortunate but it's still capable despite that; the graphics chip being absolute crap is what's killing you. 

The Direct3D version of Mark V should run on that old computer with flying colors.

It doesn't care about your OpenGL drivers ...

It doesn't even need them. 

Thanks. The laptop is probably running on old drivers, but i don't know, this laptop isn't mine, and i am doubting on updating them, as this is the only computer, i have seen running a certain videogame i like a lot, in the last 10 years.
I have been testing what you have told me and this are the results.

* Necros: About Qbism Super 8, it seems to work, at least the older versions i got from Quaddicted, the page for that in the official website gives error 80.


* Baker: About Fitz Mark V on Direct3d, yes, it works, thanks. It looks that i was using a version from before you added that feature.


* Spirit and Ericw:

The GPU is a Intel(R) 82852/82855 GM/GME Graphics Controller. GPU I855GM.

r_dynamic 0 doesn't look to have any impact on it.

Gl_info shows this:
gl_vendor: Microsoft Corporation
gl_renderer: gdi generic
gl_version: 1.1.0
Gl_extensions:
gl_win_swap_hint
gl_ext_bgra
gl_ext_paletted_texture


For now i suppose i'll stick with MArk V. It is a relief, i thought i wouldn't be able to map for the next half a year. Yeah, i know i could still amp, but mapping without checking from time to time is asking for trouble and for ending with an impossible to fix map. 

"Baker: About Fitz Mark V on Direct3d, yes, it works, thanks."

The Mark V Direct3D version can run on a 1990s clunker because it uses Direct3D's 8 API.

In fact, the only reason I made a Mark V Direct3D version was because I encountered a machine that wouldn't run the OpenGL version but was otherwise an "ok" business-like computer running Windows 7. 

I should have posted here before. 

I've changed the description of the Retroquad engine in my Patreon profile, and I need to know if it's good enough for me to spread the word around now. Suggestions are welcome.

https://www.patreon.com/mankrip 

The most exciting thing about the RQ engine is the 4-player splitscreen and controller support. Everything else is simply the icing on the cake. 

Anyway, here's a preview of the server side of my protocol code. It will support big maps but it won't be compatible with the FitzQuake protocol because the original algorithm of SV_WriteClientdataToEntity is a mess. I've only made an effort to keep protocol 15 compatibility because the original startdemos uses it.

https://drive.google.com/file/d/0BxGzcs7XcizgOW1zS0ZESmd6UGs/view?usp=docslist_api 

Retroquad is purely software rendered, no GL whatsoever? Are you making those shadows and bloom without OpenGL? 

And I'm getting better at it.

In the past I wanted to write a hardware-accelerated renderer, but I don't think that's necessary anymore.

It's a shame that Carmack abandoned his own software renderer, because the ideas behind it still have a lot of potential. The more I master it, the more things I realize that can be efficiently done.

The error most people makes is to try to mimic hardware acceleration verbatim. I'm ignoring that and focusing on the software renderer's strengths. 

So, about the description: it seems that you're speaking to yourself (a lot, by the way), not to your user. The description doesn't make crystal clear what makes RQ stands out, where's its place among other ports. Is it the "software render" guy? Is it the "console Quake" one? The "modular code port"? What's its motto? The description strikes me more like a big "thinking out loud" and less like a pitch for dummies looking for an engine like me.

Hope these 2c are helpful someway. 

Yeah you need to cut down on the ramble. To be honest you could probably cut down the text to a quarter of its size without losing the salient points.

Like this is a typical paragraph, and most of it is just waffle to be honest:

"To make sure that it all comes out as expected, with everything working well not just in the technical sense, but also in the artistic sense, one of the main guidelines I've established for this engine is "feature consistency". It means that if a certain feature is available for a certain kind of thing, it should also be available in some similar form to all similar kinds of things (e.g. in Quake, only static surfaces, MDL models and internal BSP models were lit, but in Retroquad, everything else - external BSP models, liquid surfaces, skies, 2D sprites and particles - can also be lit), and it should adapt itself to behave consistently in any user configuration (no matter the screen resolution, aspect, FOV, and so on)."

I would just turn that whole lot into a heading and a paragraph focusing on the important bit, e.g.

Feature consistency
e.g. in Quake, only static surfaces, MDL models and internal BSP models were lit, but in Retroquad, everything else - external BSP models, liquid surfaces, skies, 2D sprites and particles - can also be lit. 

First, and most importantly: It all seems as if you're asking me to pay for your hobby. I do understand that your financial situation is difficult, but I still don't really see why I should give you this money.

Second, I don't know who your target audience is. Is it players? They are not interested in all those technical descriptions I'm afraid. I suppose you're really trying to market this engine to modders and indie game developers, but even then, it remains unclear why they should choose your engine over others.

Finally, if you do target indie game developers, then you need to add a roadmap detailing when certain features will be finished and when you expect the entire project to be done. Your approach seems to be "I'll just release it all when it's done, with some files here and there when I feel like it.", but seriously, who is going to wait for that and be content to shell out their money on trust alone? I certainly would not.

To be truly honest, all this seems like you're trying to make some money off of your hobby, which in principle is fine, but in this case I think it's hopeless. Your engine is way too niche to be interesting to game developers when there are plenty of free, and already finished, alternatives out there which do run on more platforms and with a proven track record. They few things that set your engine apart don't justify the money nor the time a dev would have to wait for you to be done (which might very well be never).

I'm sorry if this sounds harsh, but it is my opinion :-( 

Hmm, let's see.

"The description doesn't make crystal clear what makes RQ stands out, where's its place among other ports. [�] What's its motto?"

Refinement.

All engines focus on improvements, but refinement is a more strict approach. Sorry, I don't know how to explain in a more concise way.

Unifying the features of all official ports is part of this refinement.

"To be honest you could probably cut down the text to a quarter of its size without losing the salient points."

That's my weakness. I'm not good resuming stuff, which is why I've asked for some opinions.

But you've cut a bit too much. The last bit is also important, because I'm not aiming just for the presence of the features. I'm also aiming to make their behavior consistent, and that's important because the vanilla software renderer behave in awfully inconsistent ways (particles becomes _smaller_ when you zoom in, for example). I just don't know how to make that clear in a more concise way. 

Those are valid points.

Yes, the target audience is also indie developers.

"but even then, it remains unclear why they should choose your engine over others."

I'm certainly not trying to compete with Unity or UE4.

And I admit that this is what I have the most difficult to answer. If an indie dev feels at home using other engines, there's no reason to change.

But, just like there still are people developing games for retro consoles such as the Genesis or the Jaguar, there may be some people interested in developing PC games with a current engine that's truly retro. I see a lot of indie games doing this with 2D engines, but 3D indie games usually tries to fake the style of software renderers using hardware renderers, what in my opinion is just plain wrong.

An indie Genesis game running on an actual Genesis is a technical achievement; a 3D game underusing a hardware-accelerated to simulate a software renderer is not.

I guess my main audience is people interested in making that kind of technical achievement, but I admit that's a really small niche indeed.

"Finally, if you do target indie game developers, then you need to add a roadmap detailing when certain features will be finished and when you expect the entire project to be done. Your approach seems to be "I'll just release it all when it's done, with some files here and there when I feel like it." "

It's not when I feel like it; it's just that I don't like to make promises I'm not absolutely sure I can fulfill, and giving exact dates is one of those promises. My life is too unpredictable, because any small problem is taking a big portion of my resources to fix. For example, if the roof of my house falls down, I'd be desperate and unable to deliver the code in time� which would make me double desperate. That's an extreme example, but it's actually possible.

I feel a lot of remorse when I don't keep up with my promises.