Another Favor/Request — General Discussion — Armageddon Games Forums Archive

MottZilla 20 Feb 2003, 03:28

I would like, if anyone who has a lower end PC, to try out the latest build of Ninja Gaiden 4, and try setting the frameskip up, to see if the game can reach a playable speed, yet without losing too much.

First, go here and download the 030204 release if you don't have that already as well as the Config program, then the 030219 lite release.

Extract 030204 to somewhere, like C:\NG4
Extract 030219 Lite to where you extracted 030204.

Run the Config program if you haven't yet.

When in the game (and you are in the level) hit the * key on your NumberPad, which enables/disables frameskip. Also, you can use F1 to see the current frameskip and FPS. Note, it only counts frames rendered, not loops.

So anyway, hit the + and - keys on the NumPad to Inc/Dec frameskip.

Give your opinion on how well the game is playable at certain frame rates, even if you aren't lower end.

If you ARE using a machine that doesn't normally reach 60FPS, set the frameskip to how ever many frames short you are getting of 60FPS * 6.

So, if you get around 20FPS, I would advise 8 frameskip (max) to 6 frameskip.

From last time I posted, FCF posted his results, and I'd really like to see how well he thinks it plays with frameskipping. So if he hasn't seen this yet, do me a favor and link him if you see him.

Not much else to say, except that I am looking into changing to tiled backgrounds, rather than the current prerendered BG map.

fatcatfan 20 Feb 2003, 05:52

Okay, the results are in.

320x240 42FPS
400x300 40FPS
512x384 40FPS
640x480 16/10
640x480 scanlines 13/9

For the first three, I used no frame skipping. It was smooth enough to play without it. For the last two, the first number is the framerate skipping off, the second with skipping on. Skipping, of course, made the animation choppy, but it sped things up enough to be playable.

Also, I realize it's just a debug string, but the "frameskipping on/off" message which temporarily appears after hitting * to toggle apparently has quit a bit of overhead in it. I saw a 4-5 FPS drop in framerate while it was displayed. This makes me think the F1 diagnostics might also be adversely affecting the framerate, though I haven't really been able to tell.

MottZilla 20 Feb 2003, 05:59

Yes, when you aren't getting 60FPS, the console string and the debug info display will slow things down a bit more.

Btw, I would advise you use a frameskip of 3 or 4 if you get 40FPS, and the game will run full speed and be pretty fast.

And could you mention your system specs again?

Also, just a note, the slowdown of the display should actually be slow now than in previous builds, as I slightly optimized that display to save some cpu time.

I suppose also I might wanna add a virtual frames per second counter, so you can see how many loops of the code are completed in a second. Should have put that in before I released.

So please post your system specs again please. =)

fatcatfan 20 Feb 2003, 06:12

[center] User posted image [/center]
200MHz non-MMX Pentium 1
128MB RAM
SharkMM Predator 4D-PCI Audio
3dfx Voodoo3 2000 PCI Graphics
Windows 98 SE

I think that's all the relevant info you could want.

MottZilla 20 Feb 2003, 06:31

Thanks. =)

I appreciate the help.

fatcatfan 21 Feb 2003, 02:03

Mottz.... why....

why is this thing using Winsock? It better not be why I think.

MottZilla 21 Feb 2003, 03:07

BlitzBasic has network support. Thus, this is always compiled in there. =\ It's wasteful I know, but I don't have an option of not including it.

fatcatfan 21 Feb 2003, 03:13

Okay. Is BlitzBasic compiling your stuff into a "tokenized" script, or actual native code? I ask because I tried to use several different exectuable exploring programs, as well as a disassembler, in order to see just what code was using those functions, and all of my normal methods crashed or failed in some form. I don't like that.

MottZilla 21 Feb 2003, 03:16

I'm not certain "where" the code goes as well. It's very odd.

You can clearly find strings and such in a hex editor, but not a single bit of the code.

So it's probably somehow stored and loaded when the program executes I assume. I could try slightly modifying a build and comparing to try to locate where it is stored.

I never bothered to in the past, and infact I'm glad that the code is somewhat protected from tampering. Anyway, look in the config program if you wish for further proof that all Blitz apps contain winsock crap and the like.

Afterall, Blitz really isn't at all ideal to make any sort of trojan in, and I'm not sure the program would function if you used a program binder.

By the way, I'm curious, why were you hex editign or disasembling it anyway? I hope you were suspecting me, and doing something else, like trying to cheat or something.