Sorry for the trouble.

The particles issue is still there with an unstripped q2.exe binary. I'll try to find the cause.

I don't know what the particle issue is. It may even be a dosbox emulation issue. We already ran into issues with dosbox not respecting dpmi linear locking/unlocking when we were trying to add SVGA and had it blow up on real hardware.

That must be it because even one of the older alpha binaries has the issue. It doesn't make sense since there are few changes in that version; I could run a diff against that version, if possible, but I bet it's dosbox specific, too.

It would help if you could send me a picture to compare so I can verify it on real hardware.

It's also recommended to use qemu or pcem if you can. Qemu emulates NICs rather easily (i know there are ne2000 dosbox ports too) so you can get online with it and have some fun as well.

I'll run inside pcem as you said. Attached is a picture, but the screenshot method I used is not ideal.

What am I looking at? I don't understand what is wrong?

Also, you really need to be using doslfn for Q2DOS. Especially online, some skin names use the skinname_i.pcx format and the _i truncates and it thinks its loading a skin twice. It causes all kinds of funny problems.

I'll show an alternate image to contrast the weapon particles...

Attached is how I expect...

I ran a diff against our ref_soft dirs, and this seems like a possibility:
+extern cvar_t *sw_particle_size_override; // FS
+extern cvar_t *sw_particle_size; // FS
+extern cvar_t *sw_particle_size_min; // FS
+extern cvar_t *sw_particle_size_max; // FS

At least it points to a feature and not a bug!

Edit:
+ sw_particle_size_override = ri.Cvar_Get ("sw_particle_size_override", "0", CVAR_ARCHIVE);
+ sw_particle_size_override->description = "Enable this to override particle size scaling with sw_particle_size, sw_particle_size_min, and sw_particle_size_max.";
+ sw_particle_size = ri.Cvar_Get ("sw_particle_size", "8", CVAR_ARCHIVE);
+ sw_particle_size->description = "How many bits to shift for particle sizes. Higher numbers are smaller particles. Use sw_particle_size_override to enable.";
+ sw_particle_size_min = ri.Cvar_Get ("sw_particle_size_min", "1", CVAR_ARCHIVE); // FS
+ sw_particle_size_min->description = "Minimum particle size. Standard formula is resolution width divided by 320. Use sw_particle_size_override to enable.";
+ sw_particle_size_max = ri.Cvar_Get ("sw_particle_size_max", "8.5", CVAR_ARCHIVE); // FS
+ sw_particle_size_max->description = "Minimum particle size. Standard formula is resolution width divided by 80 plus 0.5. Use sw_particle_size_override to enable.";

Please try the attached patch (using the diff tool and reversing the changes in the patch) to compare the particle size to without the patch. At least to find out the parameter values to the particles as intended. :)

Actually it's not a bug. :)

The particles look as expected by changing a parameter to another default value:

1- sw_particle_size_override = ri.Cvar_Get ("sw_particle_size_override", "0", CVAR_ARCHIVE);
2+ sw_particle_size_override = ri.Cvar_Get ("sw_particle_size_override", "1", CVAR_ARCHIVE);

Update: on further testing, I think the -ffast-math will be ok, but after confirming that there is a real speedup, as you noted.

Well I see a typo in my description. But don't change the code to default to it to be ON. It may mean I screwed up the scaling for the video height. In SVGA modes (Q1 also has the same issue) the particles are scaled way too huge and looked ridiculous. I spent a few hours testing every resolution to come up with something I felt looked appropriate. But, everyone may not agree, so I made a CVAR to override those values. It may even be possible that I didn't test it very thoroughly on 320x200 as I was more focused on getting the SVGA modes to not look silly.

I used 640x400 and tried 480h only. It's an interesting addition to the code and I agree that the particles are too large at low resolution.

My ports are mostly for my own amusement. When I play them (and I play them often!) whenever I see something that annoys me it has to be changed if it's within my skill level. I try to make everything toggleable by a CVAR for someone who wants a true vanilla experience.

Dunno if you had a chance to look at the emulator code yet, but apologies if it's messy. I spent a week on it getting it to a point that it worked fairly reliably. However, I've never tested it on a large scale with 100 people all talking to it at the same time, but at present it has over 700 servers listed on it and obviously a few people here have been using it for Q2DOS and it hasn't crashed or shown any extreme memory leaks so I guess it's OK.

I also noticed you stripped out gamespy (or used an older build?) and ogg/vorbis stuff and renamed or removed some comments. Some of the comments may look stupid, but I have only been programming for about 4-5 years now and I remember when I started sometimes it was really hard to understand what was going on. I try to make it as easy as possible for someone else to look and see what is happening.

Thanks! I will try it our your gamespy emulator next.

I should also mention the emulator code has only been tested on visual studio 6. It may work in linux with minor changes. I tried it in DJGPP with WATT32 but I believe it overflowed the MTU or WATT32's async i/o may be broken (it's stated as such on their site for both of these problems).

I stripped out some of the features so that I wouldn't conflict with your extensive work. I noted that in my post. So I removed anything not easily accessed from dosbox, such as networking over tcp/ip, or the use of ogg since dosbox can mount a cue/bin image. I'm not planning on updating those binaries much further, it was mainly experimental. I use an old fashioned text editing system of coding, so I may have inadventently removed comments during the copy/paste/diff procedure, but I tried to minimize my error there.