[Marscaleb]

Let me preface this whole post by saying that I'm probably not going to pursue this project, but before I throw it out I just want to find out exactly how feasible it is.

I've been thinking about creating a game which would be designed to look older; something that would have been made in the late 1990's. And, I'm wondering about building it off of a Duke3D mod. (Well, technically as a build-engine mod; I'm not sure if there is anything in Duke that I would exclusively want.)
I'm considering building it from Duke for two reasons: 1) I spent years mastering the Build editor but because fate has claimed my best work I have nothing to show for it. 2) Since I'm trying to look like an older game it just makes more sense to build it using an older engine; it just seems silly to require high-end modern machines to run a game that looks fifteen years old.

This seems like the best place to ask some technical questions since the folks here would know the most about what can be done with modding Build.

Perhaps the most critical issue I want to resolve is just about an issue regarding the graphic displays. To match the feel I want, I want all the textures to NOT be smoothed but look blocky and pixilated. To pull this off with most engines I need to create textures four times bigger to make (what looks like) giant texels, and even then they bleed together when you look closely and textures that don't tile get bleeding on their edges. It may not be a big issue for today's machines, but it just seems like a slap in the face when you have 128*128 textures that use as much memory and hard drive space as a 1024 one.
Thankfully, with Duke I can run it at its classic settings which don't smooth out the textures but keep them rough.
But that's not *quite* going to work just like that.
I want to also have some of the options that the polymost engine introduced. One, the rendering was fixed so looking up and down didn't warp the perspective. Two, and more importantly, I can replace the sprites with 3D models. As I think about this game, I just think it would look better if I used very low-poly 3D models rather than sprites. Especially for a number of decorative objects, it's simply the route I would prefer to go.

But of course, when I switch from a the classic render to the polymost or polymer or polywhateversnewest, I lose the un-blurred textures. I was just toying around with the JFShadowWarrior with no high-res stuff and once I select 16bpp I get softened textures.
BUT, I also have copies of Duke and Shadow Warrior that run on my modded xbox, based off of the JFBuild games, and they can't run 16bpp, but they can run the polymost engine. They give me the proper perspective deformations, but do not blur the textures any. So while I can't set the options in my copies on my PC, I do see a proof-of-concept that they can work that way.
Except that doesn't showcase everything. I can't set up any of the high-res stuff on that version, so I can't place in any 3D models to see if it can handle them.

So before I get into anything truly exciting I just want to know if I can (very easily) modify the game to run the polymost rendering with 3D models at 8bpp so there is no texture blurring, or if this is going to rely on OpenGL code that invariably must be rendered with softer textures.
Is there anyone here who can answer that for me?

And the next thing I am curious about it stretching what it means to be eight bits per pixel. Let's just be blunt about this, working within a 256 color palette is hard and takes some serious artistic skill. The reworked engines are designed to expand the capabilities of the graphics, and I want to see how much of that I can get. 8-bit means 256, but 8bpp is per-pixel... would it be possible run the polymost engine with, say, each texture using its own 256-color palette? Hell, even 64 color palettes works if each texture gets its own. Is there some way I could increase my color options for my textures without enabling the blurring functions that are literally hard-coded into our computers?

[thatguy]

 Marscaleb, on 01 February 2012 - 09:40 PM, said:

Perhaps the most critical issue I want to resolve is just about an issue regarding the graphic displays. To match the feel I want, I want all the textures to NOT be smoothed but look blocky and pixilated. To pull this off with most engines I need to create textures four times bigger to make (what looks like) giant texels, and even then they bleed together when you look closely and textures that don't tile get bleeding on their edges. It may not be a big issue for today's machines, but it just seems like a slap in the face when you have 128*128 textures that use as much memory and hard drive space as a 1024 one.
Thankfully, with Duke I can run it at its classic settings which don't smooth out the textures but keep them rough.

Just set the texture renderer under video options to anything with near in it.

 Marscaleb, on 01 February 2012 - 09:40 PM, said:

I want to also have some of the options that the polymost engine introduced. One, the rendering was fixed so looking up and down didn't warp the perspective. Two, and more importantly, I can replace the sprites with 3D models. As I think about this game, I just think it would look better if I used very low-poly 3D models rather than sprites. Especially for a number of decorative objects, it's simply the route I would prefer to go.

But of course, when I switch from a the classic render to the polymost or polymer or polywhateversnewest, I lose the un-blurred textures. I was just toying around with the JFShadowWarrior with no high-res stuff and once I select 16bpp I get softened textures.
BUT, I also have copies of Duke and Shadow Warrior that run on my modded xbox, based off of the JFBuild games, and they can't run 16bpp, but they can run the polymost engine. They give me the proper perspective deformations, but do not blur the textures any. So while I can't set the options in my copies on my PC, I do see a proof-of-concept that they can work that way.
Except that doesn't showcase everything. I can't set up any of the high-res stuff on that version, so I can't place in any 3D models to see if it can handle them.

So before I get into anything truly exciting I just want to know if I can (very easily) modify the game to run the polymost rendering with 3D models at 8bpp so there is no texture blurring, or if this is going to rely on OpenGL code that invariably must be rendered with softer textures.
Is there anyone here who can answer that for me?

And the next thing I am curious about it stretching what it means to be eight bits per pixel. Let's just be blunt about this, working within a 256 color palette is hard and takes some serious artistic skill. The reworked engines are designed to expand the capabilities of the graphics, and I want to see how much of that I can get. 8-bit means 256, but 8bpp is per-pixel... would it be possible run the polymost engine with, say, each texture using its own 256-color palette? Hell, even 64 color palettes works if each texture gets its own. Is there some way I could increase my color options for my textures without enabling the blurring functions that are literally hard-coded into our computers?

Sounds like you should be using the Quake engine and not Duke 3d to be honest. :/ Seems like everything you need is there without much work. Though you can definitely pull this off in Duke3d....I just don't know if you are trying to accomplish the impossible or just committing suicide?

[Hendricks266]

Set the texture filtering value to something beginning with "Nearest" to disable the blurring and restore the pixels.

You should be running 32-bit instead of 16-bit if at all possible.

You do not want to use JFSW as a base because SW is not very moddable at all. You can make new maps but that's about it.

Both OpenGL renderers support true-color textures. It should be easy to pull off an 8-bit style without the restrictions of an 8-bit palette.

I direct you here: http://wiki.eduke32.com/wiki/Main_Page

[Marscaleb]

 s.b.Newsom, on 01 February 2012 - 09:49 PM, said:

Just set the texture renderer under video options to anything with near in it.

Oh wait, I see that now. Either I never paid that any mind or it wasn't in the last version I had. (Last time I installed the then-latest eDuke I recall having my options being either an over-the-top polymer engine that crashed a lot or the original software version, nothing in-between. It ****ed me off because I wrote over an older polymost version that ran fine.)

 s.b.Newsom, on 01 February 2012 - 09:49 PM, said:

Sounds like you should be using the Quake engine and not Duke 3d to be honest. :/

Yeah, I thought about that. But the Quake engine just doesn't seem quite right. Mostly, I just can't quite explain it, but it doesn't feel right. Furthermore, I don't want to completely abolish sprites; there are a number of times I would want to use them.
Truthfully in the end, I can't come up with a solid reason to use Build over Id Tech, and I can come up with a few good reasons to use Id Tech over Build, but I just like Build more.

 Hendricks266, on 01 February 2012 - 10:30 PM, said:

You should be running 32-bit instead of 16-bit if at all possible.

Playing eDuke without the HRP, actually I find that the 16-bit renderer looks fantastic, well, from the perspective of trying to look like an older game. The slight loss of color data in poorly lit areas is nearly perfect. Unless the 16-bit render runs a risk of crashing or other failures, that's the route I would want to go.

 Hendricks266, on 01 February 2012 - 10:30 PM, said:

You do not want to use JFSW as a base because SW is not very moddable at all. You can make new maps but that's about it.

I was planning on basing things off of the JF versions since I wouldn't be needing anything from the polymer enhancements. Basing it off of SW gives me a few more enhancements like the room-over-room. Basing it off of raw Build makes sense too, since I would need to redesign all the weapons anyway.
Honestly, if I were to pursue this I would need to be modifying the original code, not just making a mod.

A big thing I would need out of it is redesigning the game logic to create some alternate modes, incorporate some RPG elements, and I would actually have to build an extension of the code to create some 2D rendering for certain segments. What I really have in mind goes beyond what can be done through basic modding and require major alterations of the source code. It would take a lot of time and research to pull it off no matter what engine I start from.

But before I get into any of that I was just curious if I could pull off the visuals I wanted, since I figured that would be the simplest thing that could stop my progress at the beginning.

[Hank]

 Marscaleb, on 02 February 2012 - 08:40 AM, said:

Yeah, I thought about that. But the Quake engine just doesn't seem quite right. Mostly, I just can't quite explain it, but it doesn't feel right. Furthermore, I don't want to completely abolish sprites; there are a number of times I would want to use them.
Truthfully in the end, I can't come up with a solid reason to use Build over Id Tech, and I can come up with a few good reasons to use Id Tech over Build, but I just like Build more.

It is settled, is it not?

[added]
So it's not a cryptic message: If you like to work with an engine, based on my own experience, there is a good chance you will enjoy working with it, despite of some missing features found on other engines you are not keen to work with. I think, if you love to work with EDuke32 just work with EDuke32.

[Carl Winslow]

the game RetroBlazer built off of the DarkPlaces version of the quake engine uses sprites and does so quite well. if you're simply not a fan of the way the player moves in quake or how objects interact, then I wouldn't be sure how simple it is to change such things.

[thatguy]

Like Colon Semicolon said, RetroBlazer is set on the DarkPlaces Quake port. They utilized both sprites and 3d models to get the exact look of what you seem to be going for.

Though if you are said to just use eDuke, then more power to you. It will be a long journey.

[ReaperMan]

 Marscaleb, on 02 February 2012 - 08:40 AM, said:

Oh wait, I see that now. Either I never paid that any mind or it wasn't in the last version I had. (Last time I installed the then-latest eDuke I recall having my options being either an over-the-top polymer engine that crashed a lot or the original software version, nothing in-between. It ****ed me off because I wrote over an older polymost version that ran fine.)

I don't recall a version like that.

Anyway i agree with the other guys, Quake engine sounds like it would be the best way to go. Just look at Retroblazer!

[Hendricks266]

 Marscaleb, on 02 February 2012 - 08:40 AM, said:

Oh wait, I see that now. Either I never paid that any mind or it wasn't in the last version I had. (Last time I installed the then-latest eDuke I recall having my options being either an over-the-top polymer engine that crashed a lot or the original software version, nothing in-between. It ****ed me off because I wrote over an older polymost version that ran fine.)

Polymost has never been removed. Keep up to date on EDuke32; all you have to do is leave the "Polymer" box unchecked, and 32-bit mode will then be Polymost. (Or, type "setrendermode 3" in the console.)

 Marscaleb, on 02 February 2012 - 08:40 AM, said:

I was planning on basing things off of the JF versions since I wouldn't be needing anything from the polymer enhancements. Basing it off of SW gives me a few more enhancements like the room-over-room. Basing it off of raw Build makes sense too, since I would need to redesign all the weapons anyway.
Honestly, if I were to pursue this I would need to be modifying the original code, not just making a mod.

EDuke32 is based on JFDuke3D and is more advanced than it in more ways than just Polymer. For one thing, it contains TROR (True Room Over Room) which is a raw engine feature instead of part of the game code like every other ROR implementation ever.

From what ProAsm has told me, modifying the SW source code is difficult and would not be very conducive to making the kind of mod you want. I would recommend against modifying the Duke source code since it is very messy and is full of hacks and hardcoded oddities. That being said, you will need to take components from it such as sound code, mouse/keyboard/input code, and so on.

[Marscaleb]

A lotta love for that RetroBlazer here. I took a look at it. I feel the need to make some connection between the inspiration they obviously took in its visual style and my avatar...

 ReaperMan, on 02 February 2012 - 03:14 PM, said:

I don't recall a version like that.

Maybe it was because of the HRP. I couldn't run anything in between the HRP and the classic mode. I couldn't just disable the HRP and play the polymer engine with classic textures, or disable all the normal and bump maps and just use the diffuse maps. In fact I still don't see an option for that. Setting the color depth to 16-bit is honestly a minor step down since the only thing I could set behind that was to jump down to the original format.

 Hendricks266, on 02 February 2012 - 05:35 PM, said:

EDuke32 is based on JFDuke3D and is more advanced than it in more ways than just Polymer. For one thing, it contains TROR (True Room Over Room) which is a raw engine feature instead of part of the game code like every other ROR implementation ever.

From what ProAsm has told me, modifying the SW source code is difficult and would not be very conducive to making the kind of mod you want. I would recommend against modifying the Duke source code since it is very messy and is full of hacks and hardcoded oddities. That being said, you will need to take components from it such as sound code, mouse/keyboard/input code, and so on.

That's some good information to have; thank you!

I suppose that I have to consent that the Quake engine would be smarter to use.

The idea was to have a game run both 3D segments and 2D segments. You go from an overhead RPG-like setting to a FPS. Only with something designed to look older would that transition have any power; in a modern game it would just be switching camera angles but in an older game it would feel like the whole game changed. And using Build seemed like the more practical choice; the jump from a sprite-based game to 3D game seems too great when you're jumping to Quake. But Duke was closer to Doom, and it seems more natural as the choice, like you could conceive of a game that actually could be designed to work that way. (And I think the engine would load slightly faster in case I couldn't successfully convince the engine to also run 2D.)

Though I suppose in the end it doesn't matter about the engine as much as the effect that is shown to the player.

[Micky C]

 Marscaleb, on 02 February 2012 - 09:56 PM, said:

Maybe it was because of the HRP. I couldn't run anything in between the HRP and the classic mode. I couldn't just disable the HRP and play the polymer engine with classic textures, or disable all the normal and bump maps and just use the diffuse maps. In fact I still don't see an option for that.

All you have to do is go into renderer setup in video options, and disable models and hi res textures. I trust no further explanation is needed. Although it would be nice if some more polymer-specific options were available to the end user.

[Jimmy]

For some reason, you strike me as yet another person who has downloaded one of those crappy all in one torrents. Disabling the HRP is pretty easy, or you could just uninstall it.

[Daedolon]

 Hendricks266, on 02 February 2012 - 05:35 PM, said:

EDuke32 is based on JFDuke3D

I thought EDuke32 is based on EDuke 2.0 which is based on WW2 GI

[Micky C]

Eduke32 is the product of dos eduke being ported to JFDuke3D by TX IIRC.

[Daedolon]

Even though that's true, I was joking.

[Sangman]

WW2GI - man that is one of the best build games. Such an underrated gem.

[Mikko]

I don't know anything about coding for Quake-based games but as far as mapping goes, a Quake editor like Worldcraft is a billion light years ahead of Build/Mapster in capabilities and ease of use.

[Plagman]

The biggest problem is all the compiling you have to do, and how everything is static. It gets really old to have to check for leaks or to constantly have to wait for lighting to finish compiling when trying to tweak how a room is lit.

[thatguy]

Well in terms of working with Quake, you'd have to pick up C++ before you can get anywhere. On the bright side with eDuke, you can just use Cons which in my opinion is a lot easier to learn than working with source code.

[Tea Monster]

There are a lot of Quake eye-candy mods available on the Quake-one site for the DarkPlaces source port. So a lot of that work has been done for you. I'm sure they wouldn't mind you using them if you asked them - they have released them as add-on packs so it shouldn't be an issue.

[Marscaleb]

 Wolfe, on 03 February 2012 - 09:30 PM, said:

For some reason, you strike me as yet another person who has downloaded one of those crappy all in one torrents. Disabling the HRP is pretty easy, or you could just uninstall it.

No, yeesh, I wouldn't do that. I don't remember all the details; it was a couple years back. I think I might have just been impatient; I was trying to get multiplayer up because I wanted to play with my brother or something. But I did write over an older version of JFDuke I got back in the day, when the HRP wasn't finished. And that version ran well but the polymer kept crashing. I didn't see any apparent option that let me run what I wanted.

 Mikko_Sandt, on 04 February 2012 - 03:45 PM, said:

I don't know anything about coding for Quake-based games but as far as mapping goes, a Quake editor like Worldcraft is a billion light years ahead of Build/Mapster in capabilities and ease of use.

That's going to come down to exactly what you are trying to do. Yes, Build requires more effort to have even a simple door, and doing slopes and room-over-room is inherently easier with a 3D brush. But if you're going for a relatively simple format you can churn something out in Build way faster and easier. If you tried to make a classic Doom style map, you could do it much faster in Build.

 s.b.Newsom, on 04 February 2012 - 05:06 PM, said:

Well in terms of working with Quake, you'd have to pick up C++ before you can get anywhere. On the bright side with eDuke, you can just use Cons which in my opinion is a lot easier to learn than working with source code.

What about later Quakes? Quake 2 and Quake 3? Hell, Doom 3 even.
If I'm migrating to Id Tech I honestly don't see a true difference between favoring any version. I mean, the "nearest" texture filtering is part of OpenGL, right? The only thing that keeps Quake 3 from using it can be overridden in the source code. (And if I'm wrong, Quake 2 still has its software renderer which pulls off the effect I'm looking for.) Even Doom 3 has its source code released so it could undergo a minor tweak on the texture filter, if all the other modifications can be made easily enough.

[Hank]

 Marscaleb, on 04 February 2012 - 07:27 PM, said:

No, yeesh, I wouldn't do that. I don't remember all the details; it was a couple years back. I think I might have just been impatient; I was trying to get multiplayer up because I wanted to play with my brother or something. But I did write over an older version of JFDuke I got back in the day, when the HRP wasn't finished. And that version ran well but the polymer kept crashing. I didn't see any apparent option that let me run what I wanted.


That's going to come down to exactly what you are trying to do. Yes, Build requires more effort to have even a simple door, and doing slopes and room-over-room is inherently easier with a 3D brush. But if you're going for a relatively simple format you can churn something out in Build way faster and easier. If you tried to make a classic Doom style map, you could do it much faster in Build.



What about later Quakes? Quake 2 and Quake 3? Hell, Doom 3 even.
If I'm migrating to Id Tech I honestly don't see a true difference between favoring any version. I mean, the "nearest" texture filtering is part of OpenGL, right? The only thing that keeps Quake 3 from using it can be overridden in the source code. (And if I'm wrong, Quake 2 still has its software renderer which pulls off the effect I'm looking for.) Even Doom 3 has its source code released so it could undergo a minor tweak on the texture filter, if all the other modifications can be made easily enough.

I think Quake 2 rocks! It's my poison and engine of choice, but not for what you plan to do though!
If you move towards id Teck 3 and above, why not look at Crytek SDK? You even can use sprites! It's a disabled feature, but if you write to
Crytek and explain your plans, you can get the relevant classes re-instated, yet the porting to XBox and PS3 will not work. I have not tested it, but there is nothing to loose in trying it for yourself.

But I repeat my first comment, stick with what you love. I spend a lot of time with Duke, no regrets. The stuff I learned in the process is/was invaluable. [added] ... by that I mean: Work with an engine you enjoy working with until you acquired enough knowledge to deside which engine is right for your project. You will know then yourself, do we actually need a given feature; does it enhance the game play or does it just look good; can we use an alternate method etc.

[thatguy]

Well if the game isn't an issue then why haven't we seen retro styled games using ID tech engines besides Quake? I think its mainly the fact that DarkPlaces is made for Quake 1 and handles everything you need to get the work done. Go ahead and use Quake 3. Good luck getting the project done without giving up because of the sheer workload. Quake 1 already has everything you need to do what you want. Quake 2 and onward doesn't.

[Tea Monster]

People have been twiddling with the Quake Engine for longer. The Source engine was based on Quake I tech, so I've been told.
In the Open Source world there was a brief interest in getting the other Q games to a more modern standard, but Dark Places just did it right so I'm guessing nobody else bothered.

Saying that, The Quake II Evolved team have recently come out of their cave withthis. So yes, work is still progressing at least on the Q2 engine at least.

If you want to see what good old D3 is capable of, check out this thread.

[Marscaleb]

Well the whole idea of using something other than eDuke was to make the needed programming work easier.
I have never worked with any mods for any Id Tech, so I honestly don't know what version is the easiest to work with.
Ideally this would come down to something being easier to build all my needed changes AND create/import some multi-angle animated sprite systems-- that this would actually be easier than making the changes I'd need inside of eDuke.
Quake 1 came out almost the same time as Duke 3D; how much easier would it be to create custom weapons and monsters and other systems in DarkPlaces than in eDuke? How much do those factors change in later Quake games? The only advantage of DarkPlaces is that I could use RetroBlazer's sprite system. But how much effort would it take to import or re-write that sprite system in a later Id Tech that (might) be easier to develop with?

Honestly I don't know; I've never worked Id Tech. That's why I was asking about it.
Honestly I'm surprised to think that it would actually take more effort to create custom enemy patterns and weapons and things in eDuke than it would to create an advanced sprite animation system AND those things in another engine.

[Hendricks266]

 Tea Monster, on 06 February 2012 - 07:22 AM, said:

The Source engine was based on Quake I tech, so I've been told.

Quake --> GoldSrc (Half-Life) --> Source (Half-Life 2)

[thatguy]

 Hendricks266, on 06 February 2012 - 06:14 PM, said:

Quake --> GoldSrc (Half-Life) --> Source (Half-Life 2)

Same with Unreal....unreal has been the same since Unreal 1.....well at least the logic of how the engine evolved.

[Marscaleb]

 Tea Monster, on 06 February 2012 - 07:22 AM, said:

The Source engine was based on Quake I tech, so I've been told.

 Hendricks266, on 06 February 2012 - 06:14 PM, said:

Quake --> GoldSrc (Half-Life) --> Source (Half-Life 2)

The IW engine is modified from Quake 3. That's the in-house engine that Infinity Ward used for their Modern Warfare games. It sure doesn't look like Quake 3; obviously they've spent a decade rebuilding it into something different.

You can do a lot with re-working an engine from its source code. But at the same time, you need basically enough skill to create a new engine before you can remake another engine into something new.

Polymer could be used to make high-end modern games on par with everything else today. The biggest change it would really need is to redesign its tool set. Worth the effort? Probably not.

[thatguy]

@Tea Monster: Those two project links really sparked my interest. Though I knew from the beginning that idTech4 was capable of, but still looks great.

[Tea Monster]

You might be interested in the Sikkmod for Doom 3 (lite versions are available for other IdTech4 games). SSAO, glow, HDR - lots of modern options. Sikkpin, who created the Sikkmod, is working with BloodRayne on upgrading GRIMM to something much better than Doom 3 graphics. BloodRayne has even got Mocap data working with monsters!

Polymer is great as far as looks are concerned, but there a lot of modern options coming along now that it dosen't support. The big problem with Polymer is that it is badly in need of optimization. You need a completely Ninja PC to basically render Doom 3 graphics, which is insane. The Eternity mod tried to use Polymer to something like what it should be capable of and nobody could run it at a decent frame rate. The other big problem with using EDuke is the lack of a particle engine and it's ancient animation system.

I've often wondered if it would be possible to take the map loading and sector rendering code of EDuke and marry it to the business end of one of the more capable Open Source game engines out there. I have no idea how possible this would be on a practical level. Just seeing some of the examples out there (Source from Quake, Brink from Q3) I keep wondering what it would be like.