How Hard would it be to port Vanilla GLQuake to Dreamcast?

This forum is for discussion pertaining to homebrew software for the Dreamcast, such as homebrew games, emulators/interpreters, and other homebrew software/applications. Porting requests and developmental ideas are not to be made here; you can make those here. If you need any help burning discs for homebrew software, this is the place to ask as well.
Post Reply
Rizzoislandgame
DCEmu Junior
DCEmu Junior
Posts: 39
Joined: Sat Dec 30, 2017 4:03 pm

How Hard would it be to port Vanilla GLQuake to Dreamcast?

Post by Rizzoislandgame » Wed Mar 28, 2018 10:13 pm

Hello again! I've been thinking for awhile, and I was wondering, that since standard OpenGL is supported, how hard would it be to do a simple GLQuake port instead of having to fix up Dreamplaces so that we can better optimize the game than whatever Dreamplaces was doing (even had it's own GL/SDL library for petes sake). Plus, though features would be missing, it would be easier to program for. What's the viability of someone helping me port this to the Dreamcast since all the other ports are either very crappy or very poorly optimized? Would it be way too hard starting from scratch?
"Smile for me, You're in loving hands
Don't be sad today, You can make other plans"

-Smile, Tom Rizzo
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5279
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Contact:

Re: How Hard would it be to port Vanilla GLQuake to Dreamcast?

Post by BlueCrab » Thu Mar 29, 2018 5:36 pm

What we have is really not anything close to a full standard OpenGL implementation. Beyond stating that, I really can't make much of a comment here, as I've never looked at GLQuake.
VladR
DCEmu Newbie
DCEmu Newbie
Posts: 3
Joined: Wed Mar 28, 2018 4:32 pm

Re: How Hard would it be to port Vanilla GLQuake to Dreamcast?

Post by VladR » Sun Apr 01, 2018 3:25 am

I just checked your current build on YT and don't understand why you insist on a heavily-indoor oriented 3D engine, while your game is mostly about outdoors (which will always be a hack in such engine and dozens of AAA developers were making those claims for more than a decade).
Then you have a problem that GLQuake in itself is another hack over the source software rasterizer. The original engine was built around completely different sets of performance bottlenecks than what DC throws in. Try looking up Abrash's Black Book for more details - it's an entertaining read, indeed.

The effort in getting GLQuake integrated into your codebase is not worth the results it will net. I believe you are far better off just designing your own 3D engine tailored to the game you work on. After all, GLQuake is only a renderer.

Don't forget, even when it's ported, there's a significant effort involved in understanding how the engine works, discovering its limitations, debugging and troubleshooting, redesigning the levels after such discoveries (and retesting them - which is a huge effort that never gets mentioned anywhere) and there will still be very costly surprises along the road.

By the time you are just about done, you'll be very angry about the effort it took, and highly likely the results will still be underwhelming, adding insult to the injury. Everybody everywhere just always makes these absurd examples that take 10 minutes to do there, so it looks awesome, yet conveniently forgets that's not remotely where most of the effort goes.


But, if you design your own OpenGL engine around the feature set you want, yes - you will initially burn a lot of time getting basics working, but with each refactoring iteration, you will get more features done, and also gradually more performance. Nothing will be hack there, as all the engine internals were built around outdoor environment from the start, and of course, around DC's core features. You will have 100% control and understanding of the whole codebase, and that will make you very powerful and efficient in coding. Good luck getting to understanding of 40% of GLQuake. Of course, you can, it's just how much time are you willing to just burn ?

When I was playing with my first outdoor 3D engine in OpenGL/C++ (I believe it was a 266 MHz Celeron and 4 MB nVidia TNT1), it actually took me only a weekend to get the basic quadtree working on the terrain and a day or two more to get the additional non-terrain objects (trees/crates/props) integrated. Less than a week to get the core working (and understanding 100%, without surprises).
Plus, while you're coding it, you are adding benchmarking/profiling code, as you go, at literally zero time cost. You always know, at every point, which functionality takes how long, and needs to be optimized further (or is "good enough"). This is usually very time-consuming with 3rd party engine, and when you finally hit that long-forgotten part of code, suddenly the build breaks, and you have to burn a day or two, just figuring out what the hell happened (it's a minefield, basically). Let's not even mention compiling times or weird broken things happening, when you insert your own variable into their code : )


A Platform, like DC, where all your coding is super high-level (C/C++), you can use floatingpoint math (!!!), you have access to something like PowerVR API, or better yet - OpenGL (basic, but beats writing your own fast texture mapper), basically unlimited RAM from code standpoint (24 MB! WTF!), streaming data from CDs, it's basically a crime not to write your own 3D renderer...
Rizzoislandgame
DCEmu Junior
DCEmu Junior
Posts: 39
Joined: Sat Dec 30, 2017 4:03 pm

Re: How Hard would it be to port Vanilla GLQuake to Dreamcast?

Post by Rizzoislandgame » Tue Apr 03, 2018 2:23 pm

Here is our conversation we had on another site so people aren't confused on what we are talking about.

Rizzo Island:

Quoted Text: "Perhaps it could work the other way ? You creating a game on my future engine ?
Maybe. The problem is that I have already put so much time into developing it with the Quake engine in mind that I already have 2 maps done and am currently hard at work on a 3rd."

I was actually thinking of creating my own engine too, and have been learning more C++ and starting to learn OpenGL, so it's portable on both windows and Dreamcast.

Could it be possible to make the engine compatible with either .map or .bsp files? .map could possibly work better to build your own map compiler as well, since bsp is very specific. Plus, that way you wouldn't need to make a proprietary map editor, and we be much more accessable to other homebrew developers. Or, you could modify GTKRadiant to output to your specific map format.

If you are able to make it, it would be nice to have it be all original code with the MIT license attached to it so it could be ported to Windows and other, more modern consoles.

Would you like me to provide a possible feature list so that you might be able to get an idea of what I want to do?
Vladr:
I hear ya with the maps, but once you go down the BSP path, you might as well just port the whole damn thing straight from Id Software anyway - what's the point of writing my own engine, if I actually use someone else's data and level structures, which btw completely define how the engine has to be written. I would really only be reimplementing carmack's implementation, and that's just a waste of my time, honestly.
"Smile for me, You're in loving hands
Don't be sad today, You can make other plans"

-Smile, Tom Rizzo
Rizzoislandgame
DCEmu Junior
DCEmu Junior
Posts: 39
Joined: Sat Dec 30, 2017 4:03 pm

Re: How Hard would it be to port Vanilla GLQuake to Dreamcast?

Post by Rizzoislandgame » Tue Apr 03, 2018 2:28 pm

Ok, but would you also make an editor that would be at least semi-easy to use so I could possibly remake the levels? In fact, like I said before, you could even modify GTKRadiant just to output to your own map file and compiler.

I really can't use normal 3D modeling software very well, so I need to have an editor that's powerful, yet easy to use.

I'm willing to make all new maps too if that's not possible, but then I would need to put out yet another demo so that people could get a better idea of what the new engine is all about and that takes time.
"Smile for me, You're in loving hands
Don't be sad today, You can make other plans"

-Smile, Tom Rizzo
VladR
DCEmu Newbie
DCEmu Newbie
Posts: 3
Joined: Wed Mar 28, 2018 4:32 pm

Re: How Hard would it be to port Vanilla GLQuake to Dreamcast?

Post by VladR » Tue Apr 03, 2018 6:26 pm

I've always written my own Level Editors for the PC games I worked on, as that's always giving you best of both worlds, though at the price of higher initial coding cost, but that effort will be very quickly offset once you hand the editor off to a remote level designer.

I tried the 3dsmax route, but since there's just so many different ways how to achieve the same thing in 3dsmax, you will get -more often than not- a max file that you can't import. The effort (basically, every time you get a max file, it will contains something new - for quite some time) required to have a fully flexible 3dsmax importer is actually higher than writing your own editor assuming you built the engine around that requirement from the start.

Don't underestimate the 3dsmax bugs, as they are plentiful, so not every export from same file will result in the same exported data. And patches. Suddenly, the exported files are completely different, and you find yourself hacking something that worked just fine last week, for no fault of yours. By the end of the dev cycle, you will find that you burnt an inordinate amount of time on something that was actually supposed to save you time.

Sure, you could attempt to enforce the "3dsmax rules", but the moment you work with more than 1 artist, it's not going to work very well, shortcuts will be taken, and mess will ensue.

So, it really is easiest to just write your own editor, and the level designers then are forced to use it and all content will 100% always be compatible, you won't end up with 3 different versions of exporter/importer and you will have zero hacks in the code.

If you can guarantee that there will only be just 1 level designer, then coding 3dsmax importer is fine. But if for whatever reason a different one comes on board, you'd have to make sure he models things the same way the previous one did. Good luck with that :)


Granted, if you want the complexity of Quake level design, than that might be a tad complex to implement a level editor for that.

But do you really need that kind of complexity for a platformer ? If you were working on an FPS game, then I would recommend just sticking to the tools available (not worth it reinventing wheel there).

But you have 100% freedom in how you design your game. Don't make it needlessly complex, if it doesn't have to be...
VladR
DCEmu Newbie
DCEmu Newbie
Posts: 3
Joined: Wed Mar 28, 2018 4:32 pm

Re: How Hard would it be to port Vanilla GLQuake to Dreamcast?

Post by VladR » Tue Apr 03, 2018 7:21 pm

Out of curiosity - did you consider simpler 3D platforming - as in Pandemonium ?
https://www.youtube.com/watch?v=mlHJ9aWD3YE

This would ensure:
- incredibly simple culling and clipping
- very limited amount of triangles
- very easy creation of levels
- easily extensible to random procedural level generation - basically you put all meshes along a NURB path
- you can have both indoors and outdoors environments
- unlike FPS games, different environments mean only a few objects and textures, or even just different textures while reusing same meshes
- constant, arcade-quality, frantic gameplay, no dull moments while player traverses hundreds of meters to next room
Post Reply