DKC Atlas Forum

[Simion32]

.
.
CLICK HERE TO BROWSE DOWNLOADS:
DELTA Game Engine - Program Releases
.
Please report all program bugs in the appropriate bug reporting topic once it is created by me.
Also, please discuss the bugs there, too, instead of in this topic, to keep things organized.
.
This is the DELTA General Discussion Topic, specifically for discussing the DELTA Game Engine that will power the DKCLB Toolkit.

[Markster]

I got some questions out Delta...

1. Will there be a Direct3D, DirectDraw, etc. graphics changing feature in Delta, so i can make it look more smooth, or sharp.
2. Will there be a limited amount of buttons, for an example, like there can only be 6 buttons, start, select, and d-pad type buttons only, or will there be more?

[Simion32]

1. This depends. I cannot modify the way the NitroGUI displays graphics, as that would break the code. I might be able to use filters similar to 2XSAI, however, as long as the code is not GPL'd (possible because of all GFX being done entirely on the CPU).

2. DELTA can accept any button that Allegro can pick up, which is pretty much everything. Configure it, and you're good to go. Control sticks might only work like + pads, though.

[Markster]

Good, i don't really care about how the graphics are displayed, i was just wondering, and i imagine that Allegro Game Programing Library would pickup a lot of buttons, well i mine as well get a game controller device that can use more buttons, i am using a SNES Controller to PC Controller adapter i got last year for Christmas, and i have tried all kinds of different DKC engines, and i usually use Joy 2 Key, and i just ordered a PC to TV video box just for Delta gameplay on my TV, i am almost prepared for Delta/DKCLB to come out.

[Simion32]

Don't expect miracles... just saying.

I've got NitroGUI cleaned up and configured for DELTA v0.0.5.0 development.

The first development build is running with the new CVideo class, which includes an upgraded timing thread (supposedly ~10μs resolution vs. the Allegro timer's ~15ms resolution).

I'll be rewriting the majority of the existing engine code, since it is almost 2 years old and is worthy of a mold infestation.

It's been so long since I've touched the core physics function that Ill need to re-think and re-code it out (very little of it was done anyway). Copy and paste, this time, is not an answer.

[Cosmicman]

I have been thinking about this for years, how hard is it to make the game so that it fills the 2 black side lines seen when playing the game in an HD screen ? I think it would be better to see the enemies from a longer distance, it will fill up the screen nicely, plus it would affect game play in a positive way.

[Simion32]

I'm still in the design phase, so any changes are welcome... but the existing design can already handle this, with one exception: Levels must use an extra screen resolution (talking relative to SNES here) if they wish to render in wide-screen properly. I'm thinking on having a level be able to support multiple camera layouts to deal with the widescreen stretch problem. Also, you can adjust it to basically whatever you want and the CViewPortal class will handle all the technical jargon of getting it to the screen the right way.

That's right, DELTA v0.0.5.0 is being designed with a "Hi-Res" Mode!!

[Markster]

Cool, i can't wait for Delta Game Engine 0.0.5.0 to come out, but to bad its gonna take a long time, ah well, take your time, don't rush development.

And i do got one more question, what are the advantages of Nitro GUI than the Default Windows GUI?

[Simion32]

what are the advantages of Nitro GUI than the Default Windows GUI?

• NitroGUI is designed specifically for games, and ease of use in a NON-MICROSOFT compiler such as GCC.
• The interface is double-buffered when possible, so that there is absolutely NO tearing or shearing of images. Nice and smooth.
• You can easily achieve 60FPS with a NitroGUI-powered game, provided you aren't trying to render too much for the GFX card to handle in one frame.
• Although the framework is currently dependent upon Win32, it is less attached to Windows itself thus enabling (eventually) a Linux port.
• It's much, much faster than the Win32 GUI due to the lack of managed code and faster graphics (although it is forced to interface with Win32 a little bit).
• It's way more flexible than Win32 window manipulation is, and the theme engine far surpasses anything Visual Studio might have up its sleeve.
• etc.

[Markster]

I got another question, would it be possible to import Delta and Nitro GUI to another device rather than the computer?

[Simion32]

I'm afraid I don't have such technological know-how...

The amount of graphics blenders that are in the core code require a lot of different graphics-math operations (add, subtract, average, multiply, screen, 16 variants of bitwise blenders, pixel-priority masking, etc and combinations of masking and the normal blenders at the same time, etc). I doubt anything other than a modern PC would be adept at running it.

[Simion32]

This is what I was talking about, here's a screen shot of the incomplete set of MMX routines direct from the project file:

Spoiler!

delta_incompleted_blender_modes.png (22.11 KiB) Viewed 295002 times

Said ASM code looks like this stuff (this is from the normal alpha blending mode):

Spoiler!

_MMXBlend_ABL:
pusha #Push Everything onto the Stack
#Load the 6 arguments into their registers
movl 36(%esp), %esi
movl 40(%esp), %edi
movl 44(%esp), %edx
movl 48(%esp), %ebx
movl %ebx, %ecx
#Each seperation pixel is 4 bytes so multilpy by 4
shll $2,52(%esp)
shll $2,56(%esp)

pcmpeqd %mm7, %mm7
psrlw $8, %mm7 #Load MM7 with Magic Pink

movl 60(%esp), %eax
jmp *jtflip(,%eax,4)
z00_doline:
#This Block Only Runs if another line has to be drawn.
movl %ebx, %ecx #Reset Pixel Counter
addl 52(%esp), %esi #Increment ESI by seperation ammount
addl 56(%esp), %edi #Increment EDI by seperation ammount
z00_start:
test $0x00007FFF, %ecx
jz z00_onepixel
z00_twopixels:
movq (%esi), %mm1
movq %mm1, %mm3
pcmpeqd %mm6, %mm6
psrld $0x08, %mm6
pand %mm6, %mm3
pcmpeqd %mm7, %mm3
pandn %mm1, %mm3
movq (%edi), %mm4
#Source: MM3
#Destination: MM4

#Process low DWORDS first
movq %mm4, %mm2
punpcklbw %mm3, %mm2
movq %mm2, %mm1
pxor %mm0, %mm0
punpcklbw %mm0, %mm1
punpckhbw %mm0, %mm2
movq %mm2, %mm6
punpckhwd %mm6, %mm6
punpckhdq %mm6, %mm6
pcmpeqd %mm0, %mm0
psrld $0x18, %mm0
pxor %mm0, %mm6
movq %mm6, %mm0
psrlw $0x07, %mm0
paddw %mm0, %mm6
pmaddwd %mm6, %mm1
pmaddwd %mm6, %mm2
psrld $0x08, %mm1
psrld $0x08, %mm2
packssdw %mm2, %mm1

# etc..........

Also, remember that I need to code SSE2 routines as well, which is many, many times more difficult!

[Markster]

Alright, since DKCRE 0.0.6.3 is out, will you be able to finally make Delta 0.0.5.X?

[Simion32]

As I have said, this is still in design phases; and due to the massive amount of things I have to cover, this is going to be one hell of a design document.

But the answer is yes, essentially.

[Simion32]

*sweat* Part 1 of the design documents is done, which simply covers the class names for all objects in all 3 games, categorizes those a little bit, and also defines a few engine limits and rules as well as some very basic layout of DELTA at the uppermost tiers.

This isn't even 1% done yet.

(Unfinished) ENGINE GLOBAL LIMITS:
MaximumTiles = ( 1024 x 1024 );
MaximumStandardTileLength = ( HexNotation( 10000 ) );
AbsoluteMaximumTileHeight = ( HexNotation( 20000 ) );
AbsoluteMaximumTileLength = ( OctNotation( 444444 ) );
MaximumPlaceableOBJs = ( HexNotation( 100000 ) );

MaximumStandardTileLength is how long , in tiles, the level can be given that it is 16 tiles (512px) tall.
Also, MaximumTiles only applies as the total number of individual tiles in the level (it can be any dimensions).
**NOTE: Tiles are not strictly locked to 32x32 in the spec, but any size of tile not equal to 32x32 will probably not have code optimization.

[WAZ__Up]

65536 objects is ALOT of objects, is that per level or the whole game?

[Simion32]

0x100000 == 1,048,576 Objects Per Level

Don't worry as I have a special data structure designed specifically to curb any slowdown due to large amounts of objects; said structure also does wonders for making collision detection faster. I'd wager with a fast PC you can have at least 256 active objects simultaneously without slowdown.

[Markster]

0x100000 == 1,048,576 Objects Per Level

Don't worry as I have a special data structure designed specifically to curb any slowdown due to large amounts of objects; said structure also does wonders for making collision detection faster. I'd wager with a fast PC you can have at least 256 active objects simultaneously without slowdown.

1048576 OBJECTS PER LEVEL!!!!!

I can't wait!

[Simion32]

The reason for the large maximum of objects is that, with the largest possible level, you can have one object per each tile. 1024x1024 = 1048576.

But yes, that is quite a lot of objects. I decided the maximum needed to be more than anyone would ever conceivably need in a level.

[WAZ__Up]

Well that would certainly be cramped haha. I converted 10,000 not 100,000. My bad.

[Simion32]

The three-digit things are "percent usage": Total, Logic, Graphics
The huge 64bit numbers are the same things but in CPU clock ticks.

TheNewDELTA_FirstTest.png (7.38 KiB) Viewed 294789 times

The new build of DELTA is up and running, and I have some more optimizations planned before I get deep into the engine itself. (Note that there are no actual menus hooked to the MenuStrip except for File>Exit and the ESC preference menu thing from that DKCRE update.)

I'm going to add a Dirty Rectangles system to the core rendering class. In this way, NitroGUI (and thus DELTA) will get a speed boost because it will then only need to send the graphics to the GPU that changed.

Since the #1 bottleneck in NitroGUI is uploading each frame to the graphics card, anything that can be done to decrease the amount of bandwidth required will do wonders in speeding up the engine.

Here's a special note: Unlike the older builds of the program, the main program currently only sends the GPU a bitmap the size of the window you are viewing. So Windowed Mode is technically faster than Fullscreen Mode (this applies to DKCRE v0060 and beyond, as well).

Oh, by the way, this is now considered to be DELTA v0.0.6.0 because of the NitroGUI upgrade (and the old v0.0.4.9 code being from like 2009).

[Markster]

I am glad you are speeding up the development on DKCLB/Delta, i think we had enough bug fixed for DKCRE this year.

----------

Delta on NitroGUI looks amazing, i can't wait, you rock Simion32.

----------

Also, did you fix those MMX problems?

[Simion32]

Heh thanks...

They were not problems, but rather missing versions of various types of blending routines. I've postponed coding them because I'm now more focused on optimizing the core engine (that is, the support code that NitroGUI runs on top of). The extra blenders can probably wait a little while, since they are "user defined blenders" and not part of the level engine itself.

I also have another NitroGUI control planned, the CPathSelectionForm - this monster control will replace the Open/Save dialogs with NitroGUI dialogs (and it will fix the "win32 dialog during full screen minimizes the program" bug). This is to be done eventually.

[Simion32]

Important Graphics Milestone Reached:

HackedStretchBringsBackOldschool.png (55.19 KiB) Viewed 294708 times

(Ignore the usage percentage meters, they tend to vary, usually around 35% total on this PC in full screen at native resolution)

Hardware stretching — without the automatic forced (and crappy) DirectDraw7 blurring!!

This hack may or may not work (I have no idea) depending on your GFX drivers, but I'm willing to bet it probably works on at least half the GPUs out there.

Obviously you must have the GFX_HW_VRAM_STRETCH_BLIT capability on your graphics card for hardware stretching to work at all.

EDIT: For those wondering, this blurring problem/glitch has been around since I first programmed DELTA. I'm very happy to have found a workaround to it!

[Simion32]

I have just completed research on SSE optimization of a copy routine which i was able to improve a little by use of prefetching. It improved the routine by 3% compared to the raw copy MMX blender, and completely steamrolled the default memcpy() by a massive 20%.

This routine can only be used in specific cases, though, so I can't really make DELTA go any faster. The key to optimization now is to ensure the engine only draws what it needs to. This is very important because (measured on this PC) NitroGUI eats nearly 33% of CPU doing its GFX.

[Simion32]

I have reached some statistics (for my PC):

Usage Item: % of 60Hz Frame Time
Copy 256x224 to VRAM: 4%
Copy 1280x1024 to VRAM: 22%
Pixelized stretch 256x224 4x using hardware: 52%
Pixelized stretch 256x224 4x using software: 11%
NitroGUI graphics rendering (no dirty rectangles): 33%

Why is the software routine five times faster than the graphics card?!?!


The possible combinations that can happen are, disregarding NitroGUI:

Copy 256x224 to VRAM and Pixelized stretch 256x224 4x using hardware == 56%
Pixelized stretch 256x224 4x using software and Copy 1280x1024 to VRAM == 33%

It looks like, to run DELTA at 60Hz you're probably going to have to use a small screen resolution (which happen to be Rare(tm) these days). That is, unless you have a crazy fast gaming machine.

So you most likely have to choose between:

• 60Hz mode and high resolution, and hope your PC is fast enough not to incur frame losses.
• 60Hz and in low resolution, with resolution blurring your picture ANYWAY
• 30Hz mode and in high resolution with no blurring

[Markster]

How's the development going on Delta at the moment?

[Simion32]

Sort of slow, I'm doing some more things with DKC3...

I have however devised (hopefully this works) an advanced bitmap layering system for NitroGUI.

This will allow a conditional bitmap copy using layers, and combined with the dirty rectangles system, will prevent the need for tons of memory to be used for the dirty rectangles. Also, this will make NitroGUI bearable on older computers.

This is what NitroGUI needs to not take 100% of your processor all the time; with DKCRE on its back the program becomes slow. In an editor program, speed shouldn't be mattering beyond "fast enough that it actually runs".

Also, the video requirements just got bumped down again, because I'm unsure that 5 screens are needed or usable in video memory. This just depends upon how all of this ends up working. Copying stuff to video memory is sometimes fast-ish and sometimes uber-slow depending upon how you do it. My current test resulted in a huge 4x slowdown VS the standard routine, but I have some ideas to (again hopefully) work around the need for the slow way of doing things.

The idea is to prevent the need to copy data if there is no need to copy it. With drawing, you have to get this down to (1) draw the GFX to backbuffer and (2) copy from backbuffer to screen. ANY more than that and you're asking for trouble.

[Simion32]

It turns out that the layering won't work exactly the way I was thinking if I program it, for one it cannot use the graphics card as I had hoped.

------------------------------

I've been droning over timing for the last few days, and I can tell you the idea/problem is simple, but the way to fix it... eh, not so much.

Game Logic Rate: 60Hz (LOCKED)
Screen Refresh Rate: ??Hz

I'm trying to find the best way to poll for user input AND update the screen, in a way that will be as smooth as possible on the user's screen - which might be refreshing at practically any rate.

I cannot use "delta timing" (that's not an LB term, it is a game technology term) to control the game, because I then loose the engine accuracy, which has to stay above all else.

I've drawn a few diagrams and thought and rethought about this for hours on end, but so far I haven't found a "perfect" solution.

The very best I can come up with is to run the gameloop at the locked 60Hz, and serve up frames to a graphics thread which does all of the put-it-on-the-screen stuff independent of the gameloop -- the screen update could then run at any rate, BUT there will be a slight input delay from when you press the button until you see it happen if your monitor is not doing 60Hz. As well as that inconsistency, every so often two frames in a row will be the same due to the engine only being able to actually render each 1/60th of a second.

Trust me, this is one of those issues I need to get right the first time. As in, the engine won't feel right unless its refresh timing works right.

[Simion32]

I've come up with a multi-threaded implementation that works very smoothly for the most part, HOWEVER, I'm still getting a pattern-based frame skip for some unknown reason. Theoretically it should be working 100% already, but something timing-related is amiss, making it miss drawing every few frames in a cyclical pattern.

Tests have not been run at above 60Hz yet, as measuring that is pointless until I've fixed this issue AND the inter-frame interpolation works.

This is the simple timing test suite of images.

test_example.png (9.95 KiB) Viewed 294552 times

[Markster]

Once you get all the problems out of the way, then whats gonna happen with Delta next?

[Simion32]

Once all these blasted timing issues are fixed, I get to dive right into the engine. Unless I'm forgetting something, which I highly doubt (the dirty rectangles may be just a bit too much to try at the moment. I'll need those for the next RE though).

[Simion32]

OK, I'd like to report that I can run DELTA at 60FPS on a 60Hz refresh rate without any frame skips, though the only existing solution uses 100% CPU (this is completely unavoidable).

I'm now working with the game loop to make it self-adjust logic calls, depending upon the monitor refresh rate. The end result should be that I have 60Hz input on higher refresh rates, with no slowdown.

But before I tackle the rest of that, I'm making the inter-frame interpolation that is needed by higher/lower refresh rates that are not strictly a multiple of 60 (or 60 divided by a power of 2). It may be difficult to come up with something that looks good.

[Simion32]

I just got to test the MMX TriProcess function, and I must say the result was much better than I expected. The function alpha blends two images as transparent with the two of them adding up to a fully opaque image. It allows something like:
"Display x% of frame 1 and 100-x% of frame 2 in the output image."
This is basically like averaging two images, but you set how visible each one is.

Of course, it's slow enough that it cannot be done on the entire screen at once (with some very rare exceptions, like if you can run 640x480x32bit@75Hz on your monitor AND your PC is fast enough). It is only really viable for post-processing on something small like 256x224, but that's exactly what i need it for!

Please note that although I am attempting to add support for high refresh rates, DELTA is designed around 60Hz and you're much better off setting your monitor to a 60Hz mode (at the smallest 32bit resolution, of course). DELTA will attempt to get 60Hz if available when going into Full Screen mode, so you won't have to bother with setting it in that case. You can usually tell that it switched refresh rates or color depth because the screen will temporarily go black.

Of course the frame modulation algorithm is sorta hackish at the moment, but I'm still working on that...


-------------------------------------
EDIT:

Skipped over to the CInput class and I'm doing some (nearly completed) upgrades before getting back to the rendering/render-timing code.

DELTA supports up to 8 controllers, and each one can have up to 32 axes (each with two digital direction "buttons") and up to 32 actual buttons.

Also, the in-game "SNES Controller Map" supports the following buttons:
(You'll notice that there are several consoles worth of buttons here.)

Start, Select, (U, D, L, R), A, B, X, Y, L, R, L2, R2
(CU, CD, CL, CR), C, Z, 1, 2, +, -, HOME, POWER
MouseL, MouseM, MouseR,

I'm extremely close to having enough to create a gamepad configuration dialog. I can even grab the name of any key you press (that's needed in the dialog to show what you have configured).

I also hope to add fully working support for using control sticks in analogue mode (that is, the way 3D consoles use control sticks). I can detect the analogue values already, but translating this into an easy-to-use "get the value" function is screwy.

[Simion32]

Ni.DLL (NitroInput Library)
(Codenamed Needle - thanks to VideoViking)

I've just completed a very important aspect of the ongoing massive input class upgrade, Ni.DLL.

This DLL contains code to efficiently catch keyboard and mouse input messages globally and store them into an on/off state table. It injects global keyboard and mouse hooks (don't worry, this isn't a virus or keylogger) into every application, thus enabling the catching of said input messages.

What's so different from this than using GetAsyncKeyState()? It is many, many times faster, because I'm not checking keys that are not explicitly pressed by the user. Other than that, there isn't much else in the way of difference between the two methods (and yes, a keylogger is technically possible with both ways - you don't need the DLL if you want to make one ).

All this said, your Anti-Virus programs are definitely going to be bashing Ni.DLL for its keylogger-like usage of keyboard hooking - but rest assured, I'm not creating any kind of virus or trojan program.

[Simion32]

Yeah, Quintuple progress update posting. Somebody reply here please...

I just completed the CInput class upgrade. The end-solution ended up not using a messaging system at all.

DELTA's rendition of NitroGUI should now be roughly 8 times more responsive than it was before!!

This is achieved by running an extra thread alongside the main one, that is controlled by a high resolution timer. It updates binary state information related to each key at a rate of a little less than 480Hz (it can't be absolutely perfect; it's always off by a bit due to thread swap overhead and such).

On each "game frame" which lasts 1/60th of a second, the game loop polls the input state objects and abstracts a proper key state out of the collected data (this state remains for the entire "game frame" unless overridden by other code).

Not only does this method mean that the controls are more responsive, but it is also very unlikely the engine will "miss" any key presses. Also, as another bonus, it means that checking for input in your custom objects will be much, much easier than if I had done a message-based system.


All that said, the input menu delay bugs in RE are actually a bug in the pop-up controls themselves, so that's still not fixed.

EDIT: Got rid of pthreadGC2.dll, since it's all Win32 code now.

[Markster]

I hope the speed of the game is going to be the speed of NTSC, I have tried DKC on PAL before, it was slower, I like NTSC speeds much better.
----------
And also, you have been through millions of NitroGUI development updates in the last several months, when is everyone going to see an update on the actual delta game its self.

[Simion32]

The speed is going to be 60Hz updates, period. I don't really care what PAL is doing (I'm using NTSC U for variables/constants/etc).

Well Markster, the good news is that all of these behind-the scenes NGUI upgrades are part of DELTA's core, and are needed to adjust it for games (input responsiveness). The input update only arose because I realized that "ghost presses" were easily possible, in which you would press the button, release, and it would never get detected. Therefore, making the input poll at a very high rate was an absolute must.

You'll probably see test update with a release after I have the video modes fixed/created. Right now, DELTA only has 256x224 windowed and maximized mode.

For it all to work on non-60Hz monitors properly, I have to add another layer of NitroGUI abstraction (don't worry, it's 95% copy-and-paste) called a CVideoBox. This will be a specialized control that's linked into the game engine's CViewPort class, which controls how the image is displayed onscreen.

After the video modes are done and the menu options are there, there is practically NOTHING left to do but the game engine itself.

[Markster]

Well that's great, I am looking forward to the next version of Delta Game Engine.
----------
And also, I got more questions about DKCLB/Delta...
1. Can you make a game of games, kinda like SMAS?
2. Can there be custom moves for the kongs, like wall pushing or something.
3. For creating save files, will people be able to make customized options, for an example, make a custom button for moving file to another empty slot, or being able to lock a password just in case someone tries to delete my save game or something.

[WAZ__Up]

well that sounds great, Now it's time for you to (in my opinion at least) do the fun part of the project

I'm not sure if this has been asked before but....
when you talk about creating objects in C# / C++ is there a code editor planned to be made for the DKCLB or are we going to have to use our own editors, like VS 2010 or something? will there be some sort of Object Development Kit along with that?

[Simion32]

Yes, I know...

All of the fun stuff has to happen on a solid foundation, though, so I can't skimp on this stuff.

Speaking of solid foundations. DELTA now supports the feature known as... it keeps running instead of crashing while you switch screen resolutions using Windows display control panel. This works even while DELTA is in full screen. Goodbye, pointless crashes!!

[Simion32]

And also, I got more questions

1. It's probably possible. Not at the point to say how easy that would be, yet.
2. Custom objects allow custom moves to be designed, of course!
3. That is actually an area I haven't even covered in thought, but I guess that's possible (again, custom stuff).

when you talk about creating objects in C# / C++ is there a code editor planned to be made for the DKCLB or are we going to have to use our own editors, like VS 2010 or something? will there be some sort of Object Development Kit along with that?

A code editor sounds like a very good idea, but that would be something for later if it ever happens. So you'll have to use your own to start out with - but you SHOULD NOT be writing managed code for custom objects (yes, that means no C# and no .NET either). Garbage collection and JIT etc would slow DELTA down tremendously - the reason I'm able to run 60Hz in it, is because it's all native C++ code.

I believe it will be something along the lines of templates that you can use to start off of along with tutorials. There will be examples for probably each generic kind of object (land, armed, water, air, and Barrel Cannons) and ones for advanced stuff like text or key combo input.

As far as environments go, the best will probably be Code::Blocks with MinGW (and all the necessary libraries). The development kit should at least include the custom Allegro 4.4.2 build.

[Simion32]

Delta Game Engine v0.0.6.B r12
YOU TEST THIS PROGRAM AT YOUR OWN RISK.

>>> DOWNLOAD LATEST VERSION HERE <<<

DELTAv006Br12.png (10.05 KiB) Viewed 294286 times

SECURITY NOTE: Your anitvirus suite will probably complain about DELTA trying to inject Ni.DLL into all processes to obtain keyboard/mouse input.
This is normal behaviour, please rest assured that DELTA is NOT a keylogger or virus.
To run the program, you may need to add exception(s) for the DELTA executable and/or DLL files.

Minimum System Requirements:

• Approximately 1.5Ghz or higher processor, preferably dual core. Any fairly recent PC should do.
• You better have a good video card (no onboard integrated graphics, please).
• 64MB available Video Memory (128MB recommended)
• 256MB available RAM Memory (512MB recommended)
• Windows XP or Higher (Vista and 7 are supported, but XP is preferred)

By the way, the menu delays and other related bugs from RE are fixed in this version of NitroGUI.

EDIT: Zip file was missing the readme, reuploaded. Hit F1 to create the file, and view it.

[Markster]

Nice, I tested it on my PC and guess what... IT WORKS SUPERB!!!
----------
I can't wait till some gameplay updates!

[Simion32]

Thanks. See, I wasn't lying when I said all that input and VideoBox stuff was necessary...

Care to be more specific? I would like to see some usage stats, and what it says your Refresh Rate is.

Also, how were the Modes? The keyboard input? What about gamepads, if you have any?

If somebody has something other than a 60Hz Refresh Rate, can you please confirm that the visuals look smooth?

Also, does the program sit idly with low usage (check Task Manager) when out of focus?

[Markster]

Well I did not try the joystick feature yet, but I did see the xxHz refresh rate, it was 59Hz, but it works smoothly though.

[Simion32]

Well, that's good to know. Having a Hz lower than 60 may cause instabilities if it's too far off.

[Markster]

If you ever need a debugger, you can always count on me, I have been using computers ever since I was 4 years old.

[HellFire]

Here i got 60hz all the time, constant so i think it ran fine, but sometimes while moving the mouse over the DELTA window I experienced some major lagging, the cursor was moving sloppy, dunno how to explain this better(my english sucks).
Also, whenever i press a button on my arcade stick, DELTA crashes. It says that it must terminate or something like that. Not that anyone will ever use an arcade stick to play Donkey Kong, but its just a PS1 controler with a ps1-> USB adapter so if i used a normal controller the same would happen. What is strange is that the directional works, only the buttons make DELTA crash. I hope this can help somewhat.

[Simion32]

The Hz has nothing to do with frames drawn. It's your monitor's refresh rate.

Try running in the lowest resolution possible, usually 800x600 (or if you're lucky, you can get into 640x480).

EDIT: Not sure about the gamepad crash. it might actually have something to do with the adapter, or the controller not being properly calibrated (DELTA expects that you've done this through windows already).