switchblade wrote:

Never really understood why the game needed an SVGA mode, considering I haven't really seen much of a difference between it and the regular VGA mode.

With the exception of the standard Mode 13h, which is the VGA 320x200 256-colour mode which has special memory handling in place (which is what also makes it backwards compatible with MCGA), all VGA modes are addressed through planar memory mapping. The irony here is that because of the extra stuff going on behind the scenes to get the normal 320x200 256-colour mode working, programming the VGA manually can actually lead to greater drawing speed if you do it right.

To that end, because Stargunner is using a 320x240 graphics mode, it MUST use planar memory mapping on VGA hardware and is completely not compatible with MCGA chipsets.

HOWEVER, the VESA 2.0 standard remaps video memory to function with a Linear Frame Buffer, thus eliminating the need to constantly change which plane you're writing to and thus improving video memory read and write speed dramatically.

Ultimately, if the speed of the computer is fast enough, you may start to outpace the video refresh rate and then the speed difference between these modes becomes pointless. However, a really good test to see the speed differences for yourself is with Duke Nukem 3D, as it supports Mode 13h, custom planar "Mode-X" VGA modes, AND VESA 2.0, though the setup program for Duke3D doesn't give you complete and total control over what's possible. For that, you have to edit the config files by hand. But, load up Duke3D on any old DOS system which can handle VESA 2.0 and try running the game in standard 320x200 mode, a Mode-X 320x200 mode, then finally an SVGA 320x200 mode, and make sure you have the FPS ticker going in all three. The framerate difference between all three of these modes may be surprising. ;)

The point though is that the reason Stargunner supports VESA 2.0 SVGA is so that the game can run 70 FPS on 486 hardware. The help docs actually recommend disabling VESA support on FASTER systems due to compatibility concerns and a DOSBox CPU cycles setting of 25,000 is actually on par with a 486 for most games, keeping in mind that DOSBox CPU cycles do not translate directly to CPU makes and speeds. :o

Joe Siegler on Stargunner Music: http://joe.siegler.net/2015/09/stargunner-music/

*checks the link and listens to the original beta tunes for the Stargunner theme song*

...uh... yeah, that definitely needed to change. :P

clueless1 wrote:

If anyone tries to get Stargunner working in pure DOS, could you report your results here? When I run the .EXE, it falls back to the DOS prompt with "Divide Overflow". Also, the DOS character size becomes gigantic until I reboot. This is on a Pentium 133. I tried with and without SETMUL (disabling L1 cache to slow system down to 386 speeds) with the same results.

I tried Stargunner (GOG download) on my Pentium 166MMX/Asus TX97-XE/DOS 6.2 PC and it works great, no crashes or any other problems. Didn't need to disable any caches or slow the PC down at all.

I also noticed that, while in DOSBox Soundblaster is better than GUS, with real hardware the opposite is true - my GUS ACE is miles better than my Soundblaster Pro 2 with both sound effects and music (the GUS is crisp and clear, while the SB Pro 2 is dull and raspy).

Calvero wrote:

Joe Siegler on Stargunner Music: http://joe.siegler.net/2015/09/stargunner-music/

I always love when juicy retrospectives from old game devs surface like this. Thanks for sharing!!

Calvero wrote:

Joe Siegler on Stargunner Music: http://joe.siegler.net/2015/09/stargunner-music/

Okay..... Those tracker tunes...... They're....... Ummmm........ Uuuuhhhh......... Well......... How can I say this.......... Very...........original...........I guess 😐 😖 🤐

The entry itself is very interesting and has some nice bits of info about the game. And that MP3 song is hilarious indeed - Lee Jackson must have had fun making it back then (even if he doesn't like his own handiwork 🤣 😁 🤣 ).

JayCeeBee64 wrote:

clueless1 wrote:

If anyone tries to get Stargunner working in pure DOS, could you report your results here? When I run the .EXE, it falls back to the DOS prompt with "Divide Overflow". Also, the DOS character size becomes gigantic until I reboot. This is on a Pentium 133. I tried with and without SETMUL (disabling L1 cache to slow system down to 386 speeds) with the same results.

I tried Stargunner (GOG download) on my Pentium 166MMX/Asus TX97-XE/DOS 6.2 PC and it works great, no crashes or any other problems. Didn't need to disable any caches or slow the PC down at all.

I also noticed that, while in DOSBox Soundblaster is better than GUS, with real hardware the opposite is true - my GUS ACE is miles better than my Soundblaster Pro 2 with both sound effects and music (the GUS is crisp and clear, while the SB Pro 2 is dull and raspy).

Appreciate you trying it out for me. I was playing the version from the 3drealms website. I'll give the GOG version a try and see if it's any different. Thanks!

JayCeeBee64 wrote:

I also noticed that, while in DOSBox Soundblaster is better than GUS, with real hardware the opposite is true - my GUS ACE is miles better than my Soundblaster Pro 2 with both sound effects and music (the GUS is crisp and clear, while the SB Pro 2 is dull and raspy).

This doesn't surprise me actually, as the SBPro is only capable of 22 KHz in Stereo mode. Would be nice to know how the GUS compares to SB16 sound. :B

clueless1 wrote:

JayCeeBee64 wrote:

clueless1 wrote:

If anyone tries to get Stargunner working in pure DOS, could you report your results here? When I run the .EXE, it falls back to the DOS prompt with "Divide Overflow". Also, the DOS character size becomes gigantic until I reboot. This is on a Pentium 133. I tried with and without SETMUL (disabling L1 cache to slow system down to 386 speeds) with the same results.

I tried Stargunner (GOG download) on my Pentium 166MMX/Asus TX97-XE/DOS 6.2 PC and it works great, no crashes or any other problems. Didn't need to disable any caches or slow the PC down at all.

I also noticed that, while in DOSBox Soundblaster is better than GUS, with real hardware the opposite is true - my GUS ACE is miles better than my Soundblaster Pro 2 with both sound effects and music (the GUS is crisp and clear, while the SB Pro 2 is dull and raspy).

Appreciate you trying it out for me. I was playing the version from the 3drealms website. I'll give the GOG version a try and see if it's any different. Thanks!

FYI, the GOG version does this same thing on my Packard Bell P133, but I did try it on another machine and it ran fine, so it's an issue specific to my PB.

Gemini000 wrote:

JayCeeBee64 wrote:

I also noticed that, while in DOSBox Soundblaster is better than GUS, with real hardware the opposite is true - my GUS ACE is miles better than my Soundblaster Pro 2 with both sound effects and music (the GUS is crisp and clear, while the SB Pro 2 is dull and raspy).

This doesn't surprise me actually, as the SBPro is only capable of 22 KHz in Stereo mode. Would be nice to know how the GUS compares to SB16 sound. :B

Fair enough Kris, I'll dig out my old CT1750 SB16 MCD and try to get it working along with the GUS ACE once again, just like the good old days ^^.

Gemini000 wrote:

With the exception of the standard Mode 13h, which is the VGA 320x200 256-colour mode which has special memory handling in place […]
Show full quote

switchblade wrote:

Never really understood why the game needed an SVGA mode, considering I haven't really seen much of a difference between it and the regular VGA mode.

With the exception of the standard Mode 13h, which is the VGA 320x200 256-colour mode which has special memory handling in place (which is what also makes it backwards compatible with MCGA), all VGA modes are addressed through planar memory mapping. The irony here is that because of the extra stuff going on behind the scenes to get the normal 320x200 256-colour mode working, programming the VGA manually can actually lead to greater drawing speed if you do it right.

To that end, because Stargunner is using a 320x240 graphics mode, it MUST use planar memory mapping on VGA hardware and is completely not compatible with MCGA chipsets.

HOWEVER, the VESA 2.0 standard remaps video memory to function with a Linear Frame Buffer, thus eliminating the need to constantly change which plane you're writing to and thus improving video memory read and write speed dramatically.

Ultimately, if the speed of the computer is fast enough, you may start to outpace the video refresh rate and then the speed difference between these modes becomes pointless. However, a really good test to see the speed differences for yourself is with Duke Nukem 3D, as it supports Mode 13h, custom planar "Mode-X" VGA modes, AND VESA 2.0, though the setup program for Duke3D doesn't give you complete and total control over what's possible. For that, you have to edit the config files by hand. But, load up Duke3D on any old DOS system which can handle VESA 2.0 and try running the game in standard 320x200 mode, a Mode-X 320x200 mode, then finally an SVGA 320x200 mode, and make sure you have the FPS ticker going in all three. The framerate difference between all three of these modes may be surprising. 😉

The point though is that the reason Stargunner supports VESA 2.0 SVGA is so that the game can run 70 FPS on 486 hardware. The help docs actually recommend disabling VESA support on FASTER systems due to compatibility concerns and a DOSBox CPU cycles setting of 25,000 is actually on par with a 486 for most games, keeping in mind that DOSBox CPU cycles do not translate directly to CPU makes and speeds. 😮

I'd love if you could provide some more technical details like this in some of your videos. Perhaps some of the filler vids?

kolano wrote:

I'd love if you could provide some more technical details like this in some of your videos. Perhaps some of the filler vids?

Only trouble is I understand the concepts but have no practical experience. I was still a kid when making stuff in DOS and I wasn't doing any assembly code, meaning I was relying on libraries or default language features to set my screen modes and such. Thus while I understand nowadays the reasoning behind the technical limitations I was working within back then, it's difficult for me to give practical examples because I've never coded to the hardware directly.

...actually, that's not ENTIRELY true... There's an old compiled QuickBASIC game on my website called "Star Gladiators 2" which if I'm remembering correctly has a tiny bit of code to reprogram the interrupt timer in order to implement decent vertical retrace syncing, thus allowing the game to run at a fixed 35 FPS. It's also the very first time I ever wrote decent AI. :B

http://www.pixelships.com/sg2_screens.html

No idea how well it runs in DOSBox... I'm gonna go try that now. ;)

EDIT: Yep, works perfectly fine in DOSBox, just gotta set cycles to max. AI is a lot easier to beat than I remember it being, but at the same time it also does a few intelligent things, such as avoiding a powerup it knows it can't get before the opponent does and switching between spreading and straight weapons depending on how close you are horizontally. I actually recall that it's possible to watch the AI fight itself without any issues too. Making it possible to intentionally level down weapons though was a bit much given the already large number of weapons to cycle between. :B

Planar Mode-X 320x200 with multiple pages is used to full effect in most Original Doom Editions. It is a big hack with confusing planar buffering. See first post in this topic: Doom in DOS: Original vs Source Ports. Note: It is also possible to use mode X whilst converting linear to planar in the final pass: All speed gain will be lost. I wonder what is the case with Duke 3D in this regard...
Linear Mode 13h is easy to work with, but regrettably IBM did not include usage of the off-screen video memory. Thus no support for smooth page flipping etc.
VESA 320x200, usually mode 150h, does not have this problem. If only it was available earlier in history, and square pixel mode 320x240 for that matter.

gerwin wrote:

Planar Mode-X 320x200 with multiple pages is used to full effect in most Original Doom Editions. It is a big hack with confusing planar buffering. See first post in this topic: Doom in DOS: Original vs Source Ports. Note: It is also possible to use mode X whilst converting linear to planar in the final pass: All speed gain will be lost. I wonder what is the case with Duke 3D in this regard...
Linear Mode 13h is easy to work with, but regrettably IBM did not include usage of the off-screen video memory. Thus no support for smooth page flipping etc.
VESA 320x200, usually mode 150h, does not have this problem. If only it was available earlier in history, and square pixel mode 320x240 for that matter.

I tinkered a ton with the video settings of Duke3D back on my Pentium 120, so I can assure you there is a huge framerate difference in Duke3D between all of these modes. ;)

I also discovered that for some reason on my old P120, with the monitor it had, if I set a VGA resolution of 360x360 the screen would rasterize much smaller and would still be 4:3 aspect. :o

Gemini000 wrote:

With the exception of the standard Mode 13h, which is the VGA 320x200 256-colour mode which has special memory handling in place […]
Show full quote

With the exception of the standard Mode 13h, which is the VGA 320x200 256-colour mode which has special memory handling in place (which is what also makes it backwards compatible with MCGA), all VGA modes are addressed through planar memory mapping. The irony here is that because of the extra stuff going on behind the scenes to get the normal 320x200 256-colour mode working, programming the VGA manually can actually lead to greater drawing speed if you do it right.

To that end, because Stargunner is using a 320x240 graphics mode, it MUST use planar memory mapping on VGA hardware and is completely not compatible with MCGA chipsets.

HOWEVER, the VESA 2.0 standard remaps video memory to function with a Linear Frame Buffer, thus eliminating the need to constantly change which plane you're writing to and thus improving video memory read and write speed dramatically.

Ultimately, if the speed of the computer is fast enough, you may start to outpace the video refresh rate and then the speed difference between these modes becomes pointless. However, a really good test to see the speed differences for yourself is with Duke Nukem 3D, as it supports Mode 13h, custom planar "Mode-X" VGA modes, AND VESA 2.0, though the setup program for Duke3D doesn't give you complete and total control over what's possible. For that, you have to edit the config files by hand. But, load up Duke3D on any old DOS system which can handle VESA 2.0 and try running the game in standard 320x200 mode, a Mode-X 320x200 mode, then finally an SVGA 320x200 mode, and make sure you have the FPS ticker going in all three. The framerate difference between all three of these modes may be surprising. 😉

The point though is that the reason Stargunner supports VESA 2.0 SVGA is so that the game can run 70 FPS on 486 hardware. The help docs actually recommend disabling VESA support on FASTER systems due to compatibility concerns and a DOSBox CPU cycles setting of 25,000 is actually on par with a 486 for most games, keeping in mind that DOSBox CPU cycles do not translate directly to CPU makes and speeds. 😮

So if I'm understanding you correctly, VESA 2.0 is rather useless in this game if your CPU is greater than a 486? Because as we've seen, if your CPU is even slightly overpowered, game speed becomes entirely unstable.

I do remember when playing the demo for this game eons ago (on my Pentium I at 133 MHZ), the game would speed up in certain areas. Sometimes it would run normally, and sometimes the game would "fast forward" at random. To be fair, I didn't bother to consider disabling VESA 2.0 on my machine at that time, which probably explains why my experience was flawed.

Then again, a fair amount of DOS games like Wing Commander (and your "personal favorite" Skunny Kart 😈 ) also had the same issue with clock speeds and game timing, so it wasn't that much of an isolated issue.

switchblade wrote:

So if I'm understanding you correctly, VESA 2.0 is rather useless in this game if your CPU is greater than a 486? Because as we've seen, if your CPU is even slightly overpowered, game speed becomes entirely unstable.

Pretty much, HOWEVER, it's this boost in speed which allows DOSBox to time things out better. If you attempt to use the VGA mode (or even the special "Tseng Video" mode) you'll need to set a different cycles count and the framerate won't be as stable since there will be a greater difference in how much CPU power the game actually needs between lulls and frantic moments.

Since you don't have direct or precise control over CPU speed on real hardware, you just have to use whichever mode works the best, if any. :P

switchblade wrote:

I do remember when playing the demo for this game eons ago (on my Pentium I at 133 MHZ), the game would speed up in certain areas. Sometimes it would run normally, and sometimes the game would "fast forward" at random. To be fair, I didn't bother to consider disabling VESA 2.0 on my machine at that time, which probably explains why my experience was flawed.

Then again, a fair amount of DOS games like Wing Commander (and your "personal favorite" Skunny Kart :evil: ) also had the same issue with clock speeds and game timing, so it wasn't that much of an isolated issue.

Skunny Kart actually has a perfectly OK timing system and so long as you don't set the game speed to 100% it will run the same speed you set on all hardware. The trouble is that it alters game speed by altering the framerate, which means if you want the game to play at an even remotely controllable speed, you have to suffer a terrible framerate, combined with unresponsive controls.

It's actually amazing how many games, even NOW, have their game speeds coupled to the framerate, especially on the console side of things where devs are guaranteed a particular level of hardware to work within. This is actually one of the benefits of so many games being made in Unity now is that at least people using Unity are being forced to implement logic code separate of the renderer. :P

I remember the Stargunner timing being OK on a non-s3vbe'd Trio64v+ 1mb with a Pentium 200 in the day.

Alright Kris, here you go - audio recordings of Stargunner from 3 different sound cards:

Stargunner - Scout Mission (GUS ACE)
Stargunner - Scout Mission (SB16 CT1750)
Stargunner - Scout Mission (SBPRO2 CT1600)

To my ears the GUS still sounds best, very clear and 'punchy'; it's hard not to notice IMHO. The SB16 does come very close, but somehow feels flat. The SB Pro 2 tries hard (I managed to get a decent audio capture) but can't measure up and sounds very restrained (probably a result of only having 22kHz stereo). Too bad I don't have a Pro Audio Spectrum sound card, otherwise I would have done a recording for comparison as well.

So there you have it. Enjoy 😀

JayCeeBee64 wrote:

Alright Kris, here you go - audio recordings of Stargunner from 3 different sound cards

Heh, nice job with that. It serves as a good comparison for sure! :D

However, I still have to disagree with you and say the SB16 sounds better than the GUS, but only as a matter of personal preference. :B

I should point out quickly that the GUS recording you took actually sounds much better than DOSBox's internal GUS support, whereas the SB16 recording sounds nearly (not exactly but really closely) identical to how it sounds in DOSBox.

The reason I like the SB16 recording better though is because, just like in DOSBox, the GUS doesn't pan to the full stereo range of the left and right speakers and internally interpolates the waveforms during mixing, which a lot of people prefer the sound of, however, I'm not one of those people and I prefer the sound of non-interpolated mixing. To me, mixing interpolation makes sound feel... well... "muffled", as if I were listening to it through a wall. Quite frankly, the GUS recording sounds more "flat" to me than the SB16 recording, especially noticeable right when the title screen opens and you hear that laser-like sound which feels like it's surrounding you on the SB16 recording, but feels more like it's in front of you in the GUS recording.

I think a part of the reason why I have this preference is because I don't hear mid-range frequencies as well as most people. I will admit too, the bass in the GUS recording is stronger and preferable to the bass in the SB16 recording, but it's not enough to get me to prefer it over the SB16 recording overall. That said, I am going to add a note on my webpage for the episode that real GUS hardware produces much cleaner audio with this game than DOSBox and that it becomes a matter of preference which is better by that point. :)

Also, for anyone else listening to all three, the SBPro2 recording is correct as Creative Labs goofed and reversed the stereo on that card internally. Whoops. ;D