NPRQuake SDL version for Windows

[JasonX]

Does anyone know if there's a version of NPRQuake SDL for Win?

[Spirit]

There is no version of the Linux SDL port of NPRQuake for Windows to my knowledge.

[JasonX]

I see... porting it to Windows would be a matter of creating a proper vid_win.c?

[r00k]

http://www.cs.odu.edu/~olson/linux/NPRQ ... g.i586.rpm

[JasonX]

Why are you linking to a RedHat package?

[Spirit]

FTEQW has some features that can create a quite similar look if I recall correctly.

Anyways, to make sure, you do realise that NPRQuake is actually a windows engine but you need SDL?

[Baker]

The "signature" feature of NPRQuake is that the renderer was separated into a .dll.

Since .dll files are platform specific, it can't be done.

But what everyone thinks of NPRQuake is the black and white animated texture thingy, so someone would need to reintegrate the external .dll file renderer source back into the engine and then SDLize it.

[leileilol]

NPRQuake has blueprint view and quake-on-me view.

http://www.cs.odu.edu/~olson/linux/NPRQuake-SDL-1.0-6jag.i586.rpm

can't be done my ass?


Also making NPRQuake as SDL on Windows would gain little benefit for that platform. Windows SDL seems to be a sin, and of course doing so would mean making MinGW/MSYS compile it as well, which is one hell of a memory leaker.

[JasonX]

NPR Quake is not only that. The way polygons are drawn is different, to simulate a hand sketch. I tried to achieve that with FitzQuake modification and failed, tried with DP as well.

[JasonX]

http://www.tempestgames.com/ryan/

SDL NPR Quake for Linux.

[r00k]

Yes JasonX I saw that page too, but the link points to a dead end. The .rpm I posted included (untested) the files that you would need.

[Baker]

NPRQuake has blueprint view and quake-on-me view.

http://www.cs.odu.edu/~olson/linux/NPRQuake-SDL-1.0-6jag.i586.rpm

can't be done my ass?


Also making NPRQuake as SDL on Windows would gain little benefit for that platform. Windows SDL seems to be a sin, and of course doing so would mean making MinGW/MSYS compile it as well, which is one hell of a memory leaker.

So am I supposed to agree with you or agree with the disagreement of you with yourself?

These are the things we need to know!

[Spike]

FTEQW has some features that can create a quite similar look if I recall correctly.

r_drawflat 2
or something.
doesn't work any more thanks to a big renderer overhaul, but the last proper release should still support it.

Basically all it is is the engine picks a random texture to draw instead of the normal texture, giving a shaded look, it then activates line drawing and draws along the edge of each polygon a few times, with a random offset.

dlls/shared objects/monkeys they work on any platform. they just have slightly different semantics, but that's not really an issue.

SDL on windows means you don't have to maintain a dedicated windows port (DP favours SDL even on windows, as it doesn't use directx, while the SDL port is able to do so - you get crap buggy sound with the win-api version). sdl doesn't mandate mingw, and msys was only ever useful in order to execute configure scripts. sdl+msvc works fine, normally.

[mh]

sdl+msvc works fine, normally.

Main problem I can think of is that (at least with newer versions of MSVC) you need to dynamically link to the MSCVRT runtimes, which means that the user needs to have them installed on their machine. But since we already need to have the SDL DLLs on, we're already on that slippery slope, so why not go for it all the way!

Not sure how nicely it plays with something like GLEW (which I've been playing with a little lately, and which I must say rocks on toast) either.

[JasonX]

Basically all it is is the engine picks a random texture to draw instead of the normal texture, giving a shaded look, it then activates line drawing and draws along the edge of each polygon a few times, with a random offset

lol, you make it sound easy.