#7 posted by metlslime on 2018/06/24 21:37:35
Does dos support any 3D APIs? If not you will be stuck using a software renderer, and no other windows functions, this might rule out all of your proposed engines. (Does mark v have a dos port?)
@metlslime
#8 posted by Caesar on 2018/06/25 00:06:10
It does, people ported Quake II to DOS and I love the software renderer so it doesn't matter, you can also add colored lighting to Quake II's software renderer if you're so inclined, there's qbism super8 which has a DOS port so you can have colored lighting and palette switching in DOS, which is really cool.
I've decided against the Quake I engine because QuakeC, and having people be able to mod what you make sounds good so I'm not too big on the Half-Life engine, which leaves it between Cube 2 and Quake II, I know nothing about Cube 2's engine.
#9 posted by mankrip on 2018/06/25 00:30:04
Cube 2 is OpenGL only. No software renderer.
#10 posted by anonymous user on 2018/06/25 04:11:08
Cube 2 Is Out Of The Running
#11 posted by Caesar on 2018/06/25 07:09:18
sysreq too high, with no clear benefit over the Quake II engine, so it's just that.
Why use ioquake? I saw nothing in Quake III I needed, I don't need shaders, Yamagi Quake II already includes support for upgraded audio, is it somehow easier to develop games with while still maintaining comparable system requirements?
#12 posted by Baker on 2018/06/25 07:47:40
Quake II, Half-Life, Sauerbraten have game logic in DLLs. C/C++ in a development experience required. Debugging DLLs is harder than even ordinary C/C++ coding.
If someone isn't regularly using C/C++ already, it would be 2 years before scaling up to be comfortable with all the hidden rules of C/C++.
For some, the significance of the above does not sink in immediately.
Usually that happens later when someone gets their hands dirty and starting trying something ...
Only then will they have that soul-killing "Oh ..." moment.
@Baker
#13 posted by Caesar on 2018/06/25 10:17:15
Well I haven't used C before, so that might be something to convince me not too.
Why is debugging DLLs more difficult than ordinary C/C++ coding?
Would coding for Quake III be easier?
@caesar
#14 posted by Baker on 2018/06/25 11:14:59
To test an external DLL used by an engine is like testing a program on top of a program, you may need to learn about call conventions or fight a development environment to get it setup.
The project files for some of those engines are going to be meant for ancient Visual Studio, Visual Studio has been updated many times since then. You'd have to convert the project, the conversion might go fine but I wouldn't expect it too. Someone with a lot of C experience could deal with conversion problems, they often aren't fun even if you do have C experience.
You might consider Unity or some actually supported engine with great tutorials for those starting and a nice choice of video tutorials.
Or if you want to use Quake or Quake 2, start with mapping and go from there ... mapping can really give some people insight into what is going on in the game. It can be a lot of fun.
/One line of thinking ...
#15 posted by mankrip on 2018/06/25 13:15:54
I wouldn't recommend idTech engines to anyone who isn't a modder with several years of experience in them.
Engines like Unity are specifically targeted to newbies. They've got tons of features and huge development communities.
Quake evolved a lot, specially in the mapping aspect, but it's still too primitive. Quake's MDL model format sucks. Q2's MD2 format still sucks. Q3A's MD3 format is fine, but Q3A doesn't have a software renderer and therefore won't run in DOS.
You've cornered yourself into using the Quake 2 engine.
Porting
#16 posted by Caesar on 2018/06/25 18:49:20
Would it be possible to make the game in another engine and make sure the game logic was as abstracted as possible from the rest of the code, the audio and rendering stuff, etc. Is there any chance I could do that and port it to another engine later? Obviously not taking advantage of Unreal specific elements, no fancy modern Unreal lighting, etc. Unreal is just C++ at its core right?
#17 posted by mafon2 on 2018/06/25 19:23:21
I'm still waiting for an oldschool shooter that would work on oldschool hardware.
Tested Ion Maiden (it's built on Build engine) – don't work on P III Win XP :-P.
#18 posted by mankrip on 2018/06/25 20:31:37
Would it be possible to make the game in another engine and make sure the game logic was as abstracted as possible
Only if your game logic is so simplistic that it sucks.
Different game engines have different physics, for example. Modern engines (including FTE) have more standard physics solutions such as Bullet. But physics are only one of the subsystems that will define your gamecode. The whole picture is even worse.
I strongly suggest that you read some detailed articles on the development of Daikatana and Duke Nukem Forever.
#19 posted by mankrip on 2018/06/25 20:35:01
Tested Ion Maiden (it's built on Build engine) – don't work on P III Win XP :-P.
Did you use its software renderer? Was it too slow, or didn't work at all?
#20 posted by Caesar on 2018/06/25 21:09:42
Ion Maiden should at least be open source, they've said they could easily make a 32-bit executable if they wanted, which they should do so the game can work on Win98 and stuff.
#21 posted by mankrip on 2018/06/25 21:27:45
Ion Maiden
Copyright © 2018 Voidpoint, LLC.
All Rights Reserved.
Build Engine used under commercial license.
Ion Maiden uses open source EDuke32 technology. The following terms apply only to the Ion Maiden game executable:
Engine code available under the Build License. See buildlic.txt.
Game code and supporting libraries available under the GNU GPL v2 with a linking exception for the Build Engine. See gpl-2.0.txt.
And
The DOS engine source and Polymost belong to Ken. Subsequent modifications belong to JonoF and Voidpoint. You can talk to us and we'll handle the legwork.
3D Realms is not a party at all.
Source
A Flaw
#22 posted by anonymous user on 2018/06/25 22:36:56
there were no 400mhz dos machines
#23 posted by Baker on 2018/06/25 23:12:07
Maybe the engine isn't such a big decision.
Maybe you get started and then find out you have don't have the talent for making an interesting game or you find out you don't have the chops to do game logic.
Whether C/C++ or QuakeC or .NET or some other language, all games require some form of coding and some form of mapping. You code in one, you'll be able to apply much of it to a different language. Same for mapping.
The difference between doers and daydreamers is that the doers get started.
The daydreamers always find a trivial imaginary obstacle that stops them from getting started so they can continue to indulge in fantasy without the risk of failure.
But it is the risk of failure that makes completing anything or leveling up satisfying.
@metlslime
#24 posted by szo on 2018/06/30 11:24:42
Does dos support any 3D APIs?
3dfx Glide, and Mesa OpenGL using Glide are the only available ones. Using Mesa, we were able to run Q1, Q2, and Sin on pure Dos in 3D-accelerated mode.
Rendition, S3DTK And SGL
#25 posted by anonymous user on 2018/06/30 21:51:07
@anonymous
#26 posted by szo on 2018/06/30 22:56:42
Rendition, S3DTK And SGL
and those are still publicly available where?
#27 posted by jorava on 2018/08/03 00:44:47
What about this? Made for standalone games: https://github.com/klaussilveira/qengine
Chosing An Engine...
#28 posted by Mugwump on 2018/08/03 02:40:09
...also depends on the specifics of the game you have in mind. For instance, AFAIK the Cube engine is the only one that has a gravity flag that you can apply to any surface. This allows the creation of pretty wild Escheresque designs. I wish someone would port this feature to Quake...
#29 posted by anonymous user on 2018/08/23 21:56:23
Cube engine is great, no idea why it did not took off.
|