InsideQC Forums

qbism wrote:Could try ditching MGL for one of the MGL-less drivers posted by mh.

It's in my plans.

However, I'm quite uninspired at the moment, and got other stuff to take care of besides this engine, so it should be a while before I work on it again. Also, being unable to figure out why the engine is crashing is quite demotivating. I'm not really good as a coder.

I'm almost certain there's at least one memory leak in the console input code, maybe some more in the rest of the console code, and maybe some more in the rest of the input code. Ditching controller/gamepad support could probably make things a bit simpler to maintain, and my code for supporting multiple controllers is kinda crappy anyway.

The startdemos code may also have a memory leak somewhere. It's just not behaving properly, at least in the Dreamcast.

I'm not sure if the Draw_Fill calls that are used to clear the screen are responsible for the crash that happens when switching to fullscreen, but I do remember that when the video mode changes, some variables are only updated in the next frame, and this may cause problems like not enough memory being allocated for some buffers. I never fully understood how the whole video mode changing code works in the Windows version, and the DC version doesn't support changing the video mode on the fly anyway.

The drawing functions for "fence textures" on BSP models are there, but the engine doesn't actually support them yet because using them for everything would generate too much overdraw, so I've gotta devise a way to only use them for drawing spans whose texture cache contains transparent pixels, including in submodels.

There are many things to fix in the TGA loading code for skyboxes.

I'd like to remove all (or at least most of) the x86 ASM code from the MDL model code. This would make it easier to expand or remove its limitations, as well as making the code easier to maintain, and the x86 ASM code is incompatible with some new features I' like to implement in it in the future.

Many parts of the 2D drawing code still are really crappy and unfinished, specially the crosshair. Also, some legacy 2D drawing functions should be removed, but I haven't yet checked to see if they're still being called by anything.

Well, the list goes on. But at least the BSP translucency support is pretty solid, and the particle drawing code is pretty much flawless. There's also a number of other good pieces of code in it, and I'm glad to have been able to get them out.

You the man Fragger!

Love, Code-Red.

regarding memory leaks, try calling #include <crtdbg.h> _CrtDumpMemoryLeaks() when quitting the program (debug versions of msvc runtime only). there's a _malloc_dbg too for tracking line numbers via wrappers too, if you need it.
or just use valgrind if you have a linux port. valgrind is awesome for detecting invalid memory accesses, its almost worth porting a program to linux just for valgrind (supposedly it can be used via wine somehow). valgrind may struggle with the heap though (although the depth buffer is on the high heap, so any access beyond the end of that should still be caught, just not underruns).

Some minutes after releasing the version 1.5.1, I've found out that it crashes randomly when running in fullscreen for a while in my desktop computer. In windowed mode it runs great. And in my laptop, which is what I use for development, it seems to run fine in fullscreen.

Running it with -dibonly didn't make the random crashes go away in my desktop computer, so ditching the MGL code shouldn't make that problem magically disappear, but now I'm going to switch to the MGL-less vid_win.c anyway. The only sad part is that the DIB code doesn't detect modes such as 1600x1200 in my desktop computer.

I'm reading a bunch of articles about code analysis, and I'll also try to learn how to properly debug programs. There isn't any other big feature I want to implement in this engine before doing that. I've tried using _CrtDumpMemoryLeaks(), but couldn't understand how it works yet. I'll study those things slowly.

_CrtDumpMemoryLeaks basically calls OutputDebugString, which means that all of its output will be visible in msvc's annoying-to-find output->debug window. It doesn't dump to stdout/stderr, but rather via some pipe to an attached debugger.

I use a 2 year old version of Code::Blocks, maybe it doesn't support that.

I'll probably have to update my development environment.

More likely the mingw libraries didnt at that time C::B is just an ide.
Id suggest using MinGW64 there libraries are a bit more up to date but CB cringes at the mingw64 host naming so get CB from my site at least as its modified for use with mingw64.

The MGL-less vid_win.c should drop in quite cleanly, and it should be a simple matter to extend the list of available modes. If memory serves the only real reason why it doesnt detect some modes is that I didn't bother changing that part of the original code - there's no technical reason why it can't detect them, however.

What's the current FPS of Makaqu on the Dreamcast? Also, how does SDL Quake perform on Dreamcast, based on that SDL port for DC?

JasonX wrote:What's the current FPS of Makaqu on the Dreamcast?

At 320x240, using the supplied PAK10.PAK and turning the crosshair on without changing anything else, "timedemo demo1" returns 20.0 fps, "timedemo demo2" returns 20.3 fps and "timedemo demo3" returns 18.4 fps.

Turning all advanced rendering features off in the options, "timedemo demo2" returns 20.7 fps and "timedemo demo3" returns 19.2 fps.

During normal play it usually runs between 15 and 25 fps, sometimes around 30 fps when rendering small areas. Dynamic lighting slows it down significantly, though.

JasonX wrote:Also, how does SDL Quake perform on Dreamcast, based on that SDL port for DC?

You mean, Bero's SDLQuake port? Very poorly.

The only way to have really good performance in the Dreamcast is by using hardware acceleration. But it wouldn't benefit the Windows version, and I don't like too much the idea of supporting two very different renderers in the same engine. I want to make the software renderer mature "enough" first.

mh wrote:If memory serves the only real reason why it doesnt detect some modes is that I didn't bother changing that part of the original code - there's no technical reason why it can't detect them, however.

The original code gives preference to some modes because of the limited slots in the video menu. It's probably because of that.

mankrip wrote:I'll keep this post updated.

... and I didn't!

Well, reading it again, there's a bunch of things I won't do anymore:

• Port to flash.
• Port to Mac.
• Port to Wii.
• Port to Nintendo DS.
• Port to PSP.

I just don't have any of these platforms, and a Flash port doesn't seem that interesting to me anymore.

There's also some stuff I already did:

• Dreamcast controller's analog stick bugfix.
• Alpha blending for BSP models.
• Automatic generation of blendmaps.
• Stippled sky.
• Test map (though a really crappy one).
• reckless' depth sorting of entities (from http://forums.inside3d.com/viewtopic.php?p=22096#22096 ).
• SV_TouchLinks fix ( from http://forums.inside3d.com/viewtopic.php?p=23999#23999 ).
• Brown/custom colored tinting of the menu background.
• BSP texture dithering on the software renderer. (still optimizing it, though)

And some others I'm certainly going to work on:

• General stability and mod compatibility improvements.
• 8-bit colored lighting in software (from either Engoo or Super8, but not until I fix the remaining instabilities introduced since the Makaqu 1.4 alpha).
• Better support for multiple resolutions (HUD/menu/console scaling, custom screen aspect, etc.) (2D scaling needs optimization, and video aspect still needs to be implemented).
• Proper implementation of Fightoon's features.
• Port to Linux.
• WAV/MP3/OGG/FLAC/ADX streaming and CDDA replacement (at least OGG).

And finally, the stuff I'm not sure if they're going to happen:

• Finish improving the controller support in Windows.
• 16/32 bit color software rendering.
• 16/32 bit colored lighting in software and hardware.
• Get the hardware renderer working.
• Hardware rendering on the Dreamcast.
• Support for the Dreamcast lightgun.
• Port to DOS.
• QuakeWorld support.

Since that first post, a lot more has been done, specially bugfixes and behavior corrections, and a number of other features were also added to my "to do" list. But this post is just an update to the first post.

Version 1.6 released.

It's still quite prone to crashing, but the current crashes are caused by old bugs which I still haven't figured out.

All of the new code introduced since the last version works incredibly fine. Mostly I wanted to share it right away so I can focus on... other things.

I don't use a repository, but a diff tool (I personally like KDiff3) should specify all of the changes since the version 1.5.1.

> QuakeWorld support.

If you want a cheap port, you can grab my qtv project ( http://fteqw.svn.sourceforge.net/viewvc ... nk/fteqtv/ ), compile it as a library, and follow the instructions given at the top of its nq_api.c file.
You'll get an additional nq 'network driver' that instead routes packets into the libqtv for translation. libqtv will do the rest.
You won't get prediction. It will only resolve certain hostnames so that regular NQ connectivity will be unaffected.
It will only work as a client, not a server.
You can play mvds with it too, but you'll likely want to knock up some extra ui/commands for that.
I've never run it/anything on a dreamcast, so I've no idea what changes you'd need for that.

I had a E1M1 crash when I gibbed a soldier and a dog and one of their gibs went into my face. I did turn on lit sprites and particles and I was playing at 1920x1080.

leileilol wrote:I had a E1M1 crash when I gibbed a soldier and a dog and one of their gibs went into my face. I did turn on lit sprites and particles and I was playing at 1920x1080.

Sounds a little bit like what was happening back when I was messing around with improving the shub bossfight a year or so back. (this was in winquake though)

Edit: you can actually crash winquake (and presumably dosquake) by noclipping into shub and hitting the right view angle. Winquake reports it as a "Double Quake Error - R_RenderView: called without enough stack"