Makaqu

[mankrip]

[qbism]

All over the code are little temporary fixed-size buffers with lines like "byte stackbuf[1024]" that can overrun when engine limits are increased. MH found that olddata in CL_KeepaliveMessage should increase, for example. Maybe one of these is lurking somewhere.

[revelator]

Hmm dynamically allocated buffers i did do some work on those in my realm engine to allow it to run marcher without setting heapsize, but there are a lot of those as you noticed.

[leileilol]

Can you take out the mouse parameter setting by default? I don't like turning off mouse acceleration in the mouse control panel after makaqu crashes.

[mankrip]

Good idea, yes. I'll turn the mouse-related commandline switches into OS-specific cvars & menu options.

By the way, there have already been a few changes and experiments made since the last release. I'm still deciding on what to do for the next version.

[leileilol]

Well having a workaround like omit drawing when an aliasmodel or sprite is too close to the screen would help.

[mankrip]

I've never had any problems or crashes with sprites. As for MDL models, that could be useful.

[leileilol]

Even the original Quake had a sprite drawing crash when it got too close to the screen! The NEAR Z CLIP code doesn't seem to help, but putting a return statement with a slightly farther distance before it did.

[mankrip]

[Spike]

less C operators perhaps.
in reality though, if r_turb_s/t is a memory operand, the shift just means that it reads a short instead of a long.
while if its a register operand then the added instruction for the shift will only cost 1 cycle, and the extra memory for the added instruction will at least partially fit inside the extra 3 bytes required for the 32bit mask value.


your real issue is that 0x7FFFFF is in the region of 8 million (more if r_turb_turb is an array of ints instead of chars/bytes). At this point you should be asking yourself how much L1 cache your cpu has. I'll help you out: not nearly that much.
'The original Pentium 4 had a 4-way set associative L1 data cache of size 8 KB'
'The original Pentium 4 also had an 8-way set associative L2 integrated cache of size 256 KB'
It also depends what else you have in memory too, like the instructions you're executing and things (so that's 2kb of your l1 gone for each separate region of memory).
We might have some awesome clock speeds nowadays, but that just means performance is more dependant upon cache speed+size than ever.
Your instructions will remain in cache the whole time. Your turb_s lookup will require 1 of your 4-way blocks, turb_t will require another, and your write to r_turb_pbase will consume the fourth. Any accesses outside of the 2k cache block will result in a cache miss. If your r_turb_t value is changing by more than 1<<11 with each iteration then you're guarenteed 2 cache misses each loop. Least-Recently-Used allocation schemes will probably result in your memory write region getting flushed at the same time (but the cpu should be smart enough to at least not flush the cache around eip).

From memory, a cache miss is about 32 cycles, and will replace part of your cpu cache resulting in more cache misses elsewhere.
A shift instruction (with register source+dest) is 1 clock.
Long story short, you've traded 2 clocks for 0-96 clocks in enough iterations of your loop, and your loop is short enough that the extra clocks are *really* noticable.

[mankrip]

[Spike]

there are other ways to do a sine table. you may find that calculating the value will be faster.
Or you can compact the sine table to 1/4th and utilise the fact that it repeats upon itself with different sign/direction within each 1/4th period.
Or you can just interpolate. Its got to be better than the rampant cache misses.

[mankrip]

Interpolation should be the easiest for me to implement. But it would slow down the rendering a bit, so it isn't a priority for me. The dithering smooths the liquids out a lot already.

By the way, the sky spans suffers from a similar inaccuracy. Their distortion is only recalculated on every 32 pixels, so there's some noticeable tearing when zooming in. That could use some interpolation, but fixing that isn't too important either.

[mankrip]

Now I'm implementing Ogg Vorbis support, and this is how it should turn out:

- Both the Ogg library and the Vorbis library are being compiled as part of the engine, directly from their sources. No external libraries, and no static libraries either.
- OGG sound effects should be fully uncompressed into RAM upon loading, to prevent negative impacts on the framerate.
- OGG sound effects may not loop.
- OGG music will be processed through Quake's audio mixer, to make it easily portable.
- Due to the OGG music being processed through Quake's audio mixer, the default samplerate will be changed to 44100 Hz.

[mankrip]

Got quickly bored with the OGG code and stopped development a couple months ago.

Now I'm simplifying the MDL renderer: Removed its x86 ASM codepath (because it's incompatible with some planned changes), and removed the old non-interpolated codepath (I'm going to make "r_interpolation 0" set the interpolation's interval to zero instead). These removals were also performed to make the code maintenance easier.

I've also implemented some code to draw a box around each MDL model's drawing area, and found out that sometimes, a model's drawing area is being shared with another model. It seems that their triangles' indexes are leaking. I already suspected that there is a leak somewhere in the MDL model renderer, and hopefully it's this one. Now it should be easier to figure out how to fix.