DKC Atlas Forum

[HellFire]

By lagging i meant slowdown. Anyway, i did not experienced any slowdown at 800x600.

EDIT: I doubt that theres some problem with my stick configuration, since i play online using it almost everyday. On ZSNES it works fine as well.

[Simion32]

It's probably DELTA neglecting some aspect of controller calibration, which causes Allegro to crash internally. This one will be a hit and miss situation until it's fixed.

It goes without saying that my controller works fine (Logitech Dual Action USB).

If you can bare to look at the "Tap F to toggle flashing FPS check" thing (don't do it if you have epilepsy), then here's how to see frame skips: if the colors continually "bleed together" to make the same color as the background, then there are no frame skips. If you see individual colors blink for a frame or two, that was a frame skip.

Also, Full Screen (F11) is much less prone to skipping.

[WAZ__Up]

Something very bad happened when i tried using it. It started out with a black window box where the app was at, then when the form loaded, EVERYTHING slowed down and i experienced the same problem the other guy did with his mouse, it was virutally usless because it only refreshed/moved every 15 seconds. and the program was slow also. when i pressed ctrl+alt+del to close it, I got a blue screen of death and had to use a system restore to load windows again

EDIT: tried it again, same thing happened except I used Alt+F4 to close instead of pressing ctrl+alt+del
also, the frame rate is always 60hz but the problem is more related to the whole thing freezing. everything stops moving and changing for about 7 seconds at a time, refreshes and freezes again. also the little counters up at the top where at %2500, %2400, %0.48 from top to bottom order. I dont know what they are for but those numbers dont look good. Changing the scale or mode didnt do anything to the speed either

[Simion32]

At this point some system specs would help tremendously. Be sure to mention what your graphics card is.

Also, let me confirm that you didn't have trouble with RE?

Very Important: What Screen Resolution did you try to run in?

FT: This is the total amount of time per ##Hz frame that the engine is eating. Common values are 99-100% for 60Hz, and 79-80% for 75Hz. Anything above that ##Hz's maximum value is a game buster - you've hit the slowdown, where the engine is consuming (in your case) far more than what time is available each "frame".

So your PC is taking 7 seconds to preform a full rendering cycle. This isn't good.

Were you not able to use lower resolutions? I hate to ask you to risk your system anymore on this...


My old Dell Dimension is far worse, it's excruciatingly slow, and breaks 10,000% FT in a few minutes.

EDIT: WAZ__Up, Is your computer single core? This could be a multi-threading spinlock issue.

ATTENTION: Cores count fix update about to be released shortly within the next few minutes.
I decided to conditionally remove the core lock on the timing thread for single-core, and the thread priority as well - it ran fast on my old DELL!

[VideoViking]

If you are testing DELTA and are having issues running it, we will need as much information about your machine as possible in order to pinpoint the problem, whether it is software or hardware related. Due to the programming nature of DELTA, Windows XP is strongly recommended, although Windows 7 and Vista are supported.

For Windows XP Users who ran DELTA successfully without problems

- Please list the Frame Time (FT), Graphics (G) and L (Logic) percentage stats exactly as it is reported on the screen. Notice that these stats will change up and down as it is running, but the range will always be stable.

- With DELTA running, press Ctrl+Alt+Del to open up the Task Manager. Click on the Processes tab and find "DELTA Game Engine.EXE." See how much CPU the program is being used: first, highlight the program, then click on the DELTA window to regain focus. You might need to move the windows around so you can get a good view (and remember, the Task Manager's window is always on top). In addition, right-click "DELTA Game Engine.EXE" and see if the option Set Affinity is available to you. If you have at least two checkboxes active and not greyed-out, then you have multicore support.

- DELTA is designed to handle screen refresh rates of 60Hz and 75Hz. Some monitors are capable of going beyond 75Hz, but will suffer from interframe blending. Some monitors can go below 60Hz, but there will be timing issues. If DELTA reports a refreshing rate of anything other than 60 or 75Hz, then try this:

1. Right-click your Desktop, select Properties.
2. Click the Settings tab, head over to Advanced. (This opens the Plug And Play properties for your monitor)
3. Click on Monitor, and see the Screen Refresh Rate setting. It is also a drop-down menu. Switch your refresh rate to either 60Hz or 75Hz, then click Apply. Your screen will shut down temporarily and refresh under the new setting (Windows will not be restarted). DELTA should also be refreshed with the new stats. Now try the Frame Flicker test: if the opposite colors flash together to create one solid color, then your monitor is ready to accept DELTA once DKCLB becomes available.

For Windows XP Users who had problems running DELTA

- We will need your computer specifications. Click on Start, point to Programs, Accessories, System Tools, System Information. This will open up a diagnostics file, containing the following required information:

1. System Manufacteurer and Model Number
2. Processor
3. Physical Memory (that's the RAM)

- To know your graphics card, right-click My Computer and select Properties. Click on the Hardware tab, and click on Device Manager. On this window, look for Display Adapters and click its plus (+) sign. You will find the name of your graphics card there. It will also say if you have integrated graphics (which in this case will list it as a chip instead of a card). (Hint: by giving us the Manufacteurer name and model number, we can review the motherboard and see what type of card it is: AGP or PCI.)

WE CARE ABOUT YOUR PRIVACY - WE WILL NEVER ASK FOR PERSONAL INFORMATION.

[Simion32]

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

>>> DOWNLOAD LATEST VERSION HERE <<<

• Added a check for single-core, and if so, it disables the timing core lock and thread priority adjustment.

EDIT: After running this version several times on my old computer, it seems that although this adjustment removed the massive slowdown issues, the timing for taking input from the keyboard/mouse/gamepad just went down the toilet.

[WAZ__Up]

Well simion, as always you seem to know just what to do to fix huge problems in 10 minutes flat ha.
Your new version fixed all my problems, running very smoothly. It just so happens that I am also running on a Dell Dimension 3000 with an Intel 82865G Graphics Controller.
The FT counter is at 100% and the G counter is at about 35% so good job at making it 71x faster

[Simion32]

OK guys, to solve all of these issues:

• Timing for input is incorrect at refresh rates of above/below 60Hz.
• Input is too slow to react on single core systems due to the OS's unforgiving thread scheduling.
• Ghost Press issues, where keys can be missed. Applies more to the gamepad than the keyboard at the moment.
• Needing two threads is (for all systems) wasting time and performance on mere thread scheduling.

I'm going to need to revamp the input methods again. This time I need completely message-based input collection which will abstract into the usual NGUI input functions that I already have. This is a fairly large modification, so it may take a few days to get straight.

The idea is for all input messages to be timestamped. I can then determine, with absolute certainty, when an input message was received; and with that ability, the correct input for that frame can be "taken in" by the game engine as necessary.

No delays or missed keys, no timing loops to waste processor cycles, and response times as fast as windows can detect input events (typically driven by interrupts, which are instantaneous).

Also, this may or may not provide a fix for HellFire's issue with buttons crashing the engine. I cannot be sure it will, at the moment.

EDIT: There's a pretty good chance this modification will make USB controller hot plugging possible. YES!

EDIT2: The input will be fairly easy to complete, however I'm tackling some DLL-related issues before resuming that.

EDIT3 (Sep 21st): DLL stuff is complete. Working on the input now (I have some documentation on how to do it by now).

[Simion32]

I've just completed the value table for keys (this is instrumental for users designing their custom objects).

Programming on the actual state collection is to commence shortly.

Also, it will be able to support multiple mice in fullscreen, and up to 8 players (each which may have a mouse, keyboard, and/or gamepad).

I'm also working on getting hot plugging capability into this, though the code is going to be very esoteric.

[Markster]

8 Players? That is a lot of player, too bad my family and friends don't care for DKC at all
----------
What do you plan to do update on the next version of Delta Game Engine, are we going to see some game-play updates yet?

[Simion32]

Patience, my friend. Gameplay updates will come soon.

Right now I'm about 88% of the way done with this new input upgrade. I can detect input reports coming in (by having it play a sound on each input update, which is anytime anything changes).

Keyboard updates: Data collection runs properly, no crashes.
Mouse updates: Data collection runs properly, no crashes.
Gamepad updates: UPDATE: Data collection now runs properly, no crashes. [Working on a very tough bug I hit this afternoon. HidP_GetUsages() - which is supposed to tell me which buttons (they call 'em usages) are pressed - is crashing because one of the parameters I must provide to it is NULL. I still have no idea what's going on or why it is NULL.]

Trust me, this is some confusing **** -- but it MUST be done this way.

After the collection works properly, I just have to make the function that takes this input work with the data format that the collection routine sends (especially important for gamepad axes and such).

After this is done, I'll be able to fix the above list of problems, and I can get on with the engine itself.

I'm sorry I've had to redo the input so much, but this is what it came to, for it to work the correct way.

EDIT AT 3 IN THE MORNING: The NULL pointer bug has been fixed with some C++ pointer math to obtain the pointer manually. It now works as if nothing was ever wrong!

[Simion32]

I just got through some brain bashing mathematics code to calculate the input timebase.

Here's a diagram showing what exactly DELTA has to orchestrate:

The math to calculate the correct input delays will make your brain turn to mush.

DeltaUpcoverting60Hz75Hz.png (19.92 KiB) Viewed 161941 times

Don't worry, progress is still being made on the rest of the input code, it's just a much more vast undertaking than I previously thought, covering some unknown territory as well. I'm going as fast as I can!

EDIT Midnight/Sep-30th:
I literally JUST got DELTA running again with the new input method! I am still not done with this, though, as there are multiple bugs with the mouse and a slew of code left to put in.

I also have to switch it over to the "buffered" version of Raw Input, because far too many messages come from axis-based controls for it to work normally using the current method (the messages pile up and don't register all in the same frame, causing "input overload" delays when you're moving a gamepad stick, or the mouse, or something else like that).

[Markster]

I got a tank full of questions about Delta Game Engine and Donkey Kong Country Level Builder again.
-----------
1. Can you make a game that runs higher or lower resolution than 256x224.
2. Will there be a lot of graphics options, like smoothing, sharping, contrast, etc.
3. How fast would it work on older computers, like an old Windows XP computer with only 512MB of RAM.
4. Would it be okay to upload DKCLB games to DKC-Atlas. (I know ROM files are not okay.)
5. What are you gonna do about some sprites for some characters that don't exist, like Dixie's and Kiddy's rope swinging animation.

[Simion32]

1. HiRes Mode enables the screen to be set to whatever size the level designer wishes, per level. Please note that due to CPU requirements, increasing this too much may limit the amount of users that can play your levels!

2. I'm not all too sure about image smoothing algorithms as they take as much as or even more time than alpha blending does. Someone would have to code one in MMX or something.

3. You're talking about my old DELL Dimension here. Provided you set the resolution as low as possible (you really want 640x480) and you're not playing levels that render a huge screen, you should be OK. Also you must be sure to have a graphics card capable of displaying the new graphics each frame (have to upload to the graphics card upon each monitor refresh, which isn't exactly fast -- and takes the majority of DELTA's CPU time). Most onboard laptop graphics fail at doing this since they are not designed for gaming, though high-end laptop made for gaming might be able to run DELTA.

4. As far as uploading goes, that would be a complicated question we'd have to ask Qyzzy about - I'm completely unsure of the kinds of file sizes that will result from whole DKCLB games, though levels are extremely small (in the tens of kilobytes range, last I remember with the old DELTA - this could change slightly since the old format was only storing tiles and music IDs. The ID system for the full LB takes 64 bits per ID).
Of course, with an LB game you only need to share the content that DELTA/LB does not initially extract from the DKC ROMs, which means you (hopefully) wouldn't be distributing copyrighted materials anyway. Custom sprites are probably OK, but I'm not all that sure about "custom" music or sound effects.

5. I have no idea, really.

[Simion32]

Progress Update:

The last few days have been busy, but I have most of the "global" input bugs fixed. It is now time to work on the multiple-players code and the controls configuration dialog (yes, this is absolutely required later for game play testing).

I've also implemented a new feature during the process of fixing input bugs, for those who get pushed around by windows' display settings...
Alt+F11 and Ctrl+F11.

Alt+F11 will attempt to take you into 800x600 fullscreen mode, at the suggested 60Hz if possible (you can change the suggested value through the Configuration INI). If this fails, it falls back on normal fullscreen mode.

Ctrl+F11 will attempt to take you into 640x480 fullscreen mode if possible. If this fails, it falls back on the Alt+F11 function, and then normal fullscreen if that also fails.

Spoiler!

DELTA overrides Print Screen, and dumps out its own screen shots instead!

DELTA_640x480.png (16.04 KiB) Viewed 161839 times

[Simion32]

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

>>> DOWNLOAD LATEST VERSION HERE <<<

• Massive Input Upgrade.
• Only P1 detects input so far!
• Device hot plugging is possible if your input device is USB based.
• DELTA does its own print screens, saves to "ScreenShots" folder.
• Cheat detection test (keyboard only so far).
• In-game mouse cursor is now working.
• Added Ctrl+F11 and Alt+F11 features.
• Several full-screen minimize bugs hunted down. Thanks for testing, VideoViking!
• Ni.DLL is no longer needed for operation.
• DELTA reduces CPU usage upon minimize or going out of focus.

NOTE: CPU saving features will not work on all computers and/or every single time. There can be some optimizer programs that will either screw with the processor or play tricks on DELTA's focus detection heuristics. It can sometimes result in DELTA spinning the CPU while not in focus, so be forewarned.

To control the screen parameters, you can use the numpad keys:
From numlock to 3 are the anchor;
+ and - change the scale;
0 and decpoint change the mode.

[Markster]

Wow, it is amazing Simion32, I did not even know you where planning to have in-game cursors in Delta, I can't wait to control the DKC3 cross-hair in the bonus round with my mouse.

[Simion32]

Have any Game Pads that you can test? We haven't had anyone test any yet other than me, so it would be highly appreciated.

[WAZ__Up]

well I have a ps2 to USB adapter for my ps2 controller. But my controller is very old and its not working properly with ZSNES and some buttons dont work anymore. Although I can still test it to see if it gets any input at all.

[Kingizor]

...

After 25-35 seconds, I get extreme lag. The mouse slows down and takes much longer to react to movement. This seems to get gradually worse. The same thing happens with inputs and normal key presses. This affects all things globally.

CPU usage starts at about 40-50% and only increases. Probably related to the ^above^ thing.

Logic seems to be fixed at 1%...?

The process seems to remain in memory after closing the program.

Controller seems to work perfectly.

[Simion32]

After 25-35 seconds, I get extreme lag. The mouse slows down and takes much longer to react to movement. This seems to get gradually worse. The same thing happens with inputs and normal key presses. This affects all things globally.

Do you have a high-end keyboard/mouse? The only thing I can think of is that a device is sending far too many input messages for DELTA to handle (and yes, there is something I can do to fix this).

The process seems to remain in memory after closing the program.

Probably due to an internal crash related to the input message overflow. It's the only thing I can attribute it to at the moment.

[WAZ__Up]

My ps2 controller works well with it, even detecting axis movement.

[Kingizor]

Do you have a high-end keyboard/mouse?

Simple run-of-the-mill USB laser mouse and a very old, but reliable keyboard. So yeah, probably the mouse, although I've had it so long I've forgotten what it's really capable of. I've also got my graphics tablet plugged in all the time, but I don't really suspect it. Time for interrogation.

Probably due to an internal crash related to the input message overflow.

Yes, I've just noticed that this isn't happening every single time; only when the programs been open for more than a few seconds. Hmm...

[Simion32]

DELTA will pick up anything that windows sees as a mouse, keyboard, or gamepad/joystick.

There are essentially 3 categories:
(1) Mice
(2) Keyboards
(3) Game controllers and everything else

Some devices may report themselves as a mouse or keyboard for interoperability with Windows. I've read that some remote controls do this.

[Kingizor]

Any documentation that might have came with the mouse is probably long gone... A highly suspicious ebay listing for the same model tells me it is capable of 1200dpi.

[Simion32]

Yeah, that sounds like it's the problem - the mouse's DPI is so high that it swamps DELTA with mouse move messages, eventually also overflowing the input message spool (which at the moment contains an absolute maximum of 2048 total spooled event records).

I'll need to make it use buffered input (takes arrays at a time) and increase the spool storage (per player that is).

[Kingizor]

First:
Tried input with only my graphics tablet - same problem. It probably has a similarly high dpi like the first mouse.

Second:
Tried with a ps/2 mouse that I had in a drawer - same problem. This mouse definitely isn't as fancy as the others.

Third:
Tried with my third mouse, which is also a very fancy laser mouse - no problem! This one has the ability to switch between 400, 800, 1200 and 1600 dpi with the click of a button, and is the prettiest, fanciest, most spectacular mouse I own!

[Simion32]

OK, so that confirms it. I'll go ahead with the modifications since not everyone has a mouse that can adjust the DPI. Mine is probably 200dpi or something extremely low.

Also, the DELTA mouse input forces direct use of mouse mickeys as the unit of measurement. I cannot pick up cursor coordinates for more than one mouse, because Windows does not support this.

So I lock the cursor to the mouse mickey -based position of P1's mouse, and all the other players' mice do the same but will only possibly show up as a game cursor within DELTA's game display area (as mentioned before, all input is pipelined to P1 at the moment, there needs to be a configuration dialog before DELTA can separate out the inputs to each individual player).

[Markster]

This may be unrelated to what your talking about, but I want to use DKCLB and DGE so much, that I would build a time machine and travel in the future to freaking use it, come on, a remake of DKC1, 2, and 3 for the PC that is much much more powerful than the original and is meant to make custom levels on.
----------
And also, I got more questions about Delta Game Engine and DKCLB.
1. If I had a powerful gaming computer (12GB of RAM standards.), how powerful could Delta Game Engine be?
2. Can you customize the HUD for your games in DKCLB, like adding a HUD item for banana coins in DKC1 or something, or making a brand new HUD similar to the one in SMB3, where nothing is blocking the screen, just a big bar at the bottom or top.

[WAZ__Up]

If I were to answer your HUD question, I would say theoretically, yes. I would say make a custom object using the banana coin sprite and have it appear at the top along with its value every time you collect a coin. This action would be triggered by the coin_count variable increasing by one. Same thing for everything else. I can assume that standard DKC1 HUD items like lives, ect. can be re-positioned but If not, then who's to say you cant create your own custom object appear in view everytime you collect a life, and at the same time stopping the regular HUD life balloon from showing up at the top.

These are just ideas from somebody who isnt actually MAKING the thing, so I dont know how possible that actually is to do.

[Simion32]

The HUD elements are special objects that use the stats layer, which is for sprites appearing in front of the action. These sprites can either lock to the screen, or can also move with the level. But this layer is normally for counters and etc, such as the rocket fuel gauge from DKC3 (and all item counters too).

Where was that layering diagram I had... oh wait, there isn't one. I revised it at some point to allow variable amounts of layers:

Canvas Color
Backgrounds
Main Grounds (physically touchable layers)
Foregrounds
Stats Layer (Super TopMost, the only things that can cover this are special effects)
...and...
[Sprites] (sprites must be above the Canvas Color, but can be anywhere above or behind any of the other layers)
[Special Effects] (special effects might be only at one point in the stack, or might cover several layers, or might be attached to sprites)

I believe the limit per each type of layer was 4 of them, with no arbitrary limit on the number of total layers (only one stats layer though). There's really no limit to where sprites can go, either.

But yeah, you can make a custom object to go on the stats layer, as it's just another layer (which you can also put sprites on). You can even take off the old ones if you want.

The item counts will likely be handled via properties of some sort, that can be "per-level", "per-world", or "global". The properties could have a flag to designate whether to save the value to the game save file, and another flag to designate whether the property gets reset upon level re-entry, etc (think DK Coins).

If I had a powerful gaming computer (12GB of RAM standards.), how powerful could Delta Game Engine be?

The key factors with DELTA are, in order of importance:
GPU Image Upload Speed (AGP likely to be faster) << This is the bottleneck in DELTA that takes at least 10% CPU.
RAM Access Speeds (graphics processing in RAM becomes faster with faster RAM)
Processor Speed (and possibly # of Cores/CPUs)

Everything else, including extra RAM, won't make DELTA run any faster, it'll just have more edge-room. Faster HDD's will only make the loading process for levels faster, but has no effect on engine performance.

[Simion32]

Progress Update:

In the process of adding the CTabControl and its CTab's to NitroGUI for DELTA's controls configuration dialog, I hit a few snags.

NitroGUI is now undergoing some short-but-complex modifications to fix these issues and simplify the process of adding controls (and prevent me having to search through a 6000+ line, 222KB code file to change one parameter). Said modifications are already roughly 75% done.

[Simion32]

Progress Update:

The NitroGUI modifications are complete (they were several hours ago but I've been busy with chores and so couldn't post).

I'm now focusing in on the remainder of the input bugs (including Kingizor's issue), and then I'll be tackling the big kahuna: the Control Configuration dialog.

I have the strangest feeling that Kingizor's issue won't be fixed even after I make the buffering adjustments, but maybe that's just me.

Oh, and my mouse's DPI is most likely 800.

[Simion32]

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

>>> DOWNLOAD LATEST VERSION HERE <<<

• NitroGUI Upgrade that also automated a bunch of stuff.
• The mouse lag fix has been attempted. Kingizor needs to test this one.
• Remnant input bugs in NitroGUI from the input upgrade have been quashed.
• Fixed some mouse focus update bugs involved with mode switching. The game cursor no longer jumps around.
• The Configuration.INI file layout has been changed up a little.
• Various other smaller bug fixes.

To control the screen parameters, you can use the numpad keys:
From numlock to 3 in a rectangle are the anchor switches;
+ and - change the scale;
0 and decpoint change the mode.
Also: F11 for full screen, Alt+F11 to try 800x600, and Ctrl+F11 to try 640x480.

Comments on the mouse fix: I have a feeling the issue isn't actually mouse DPI, but is updates per second. A very high update Hz would more than likely cause WM_INPUT message overflows.

BUG FOUND: It appears there is a window sizing bug preventing the resize from actually happening.

[Kingizor]

Notes:

There are signs of input delay from the beginning. That is, moving the mouse and the screen updating slightly later. I initially put this slight delay down to double buffering or vsync, or whatever. It's much more noticable with a mouse than any other form of input. Just mentioning it in case it's related. This is not always present. It doesn't seem to happen in 640x480@60fps (screen mode 4), unlike 1920x1080@60fps.

The usual problem persists; after a certain amount of time, lag starts to build. Moving the mouse or any other form of input is not immediately registered. This continues to get worse.

By starting the program in screen mode 4 (640x480@60fps), the same thing happens, but it seems to happen a bit later (i.e. it takes longer for the problem to start and progress?). Seeing as there is no timer anymore, I can't be sure --Possibly my imagination..

The fact that the problem did not occur while using one particular mouse is odd. I have no idea why, or if it was just a fluke.

"Buffered Input Read Count" seems to be rather unusual. The value starts rather low, and does not immediately rise when using the inputs. After a few seconds it begins to rise whenever I do something, e.g. when the mouse is moved. It continues to rise alongside mouse movements. After a certain amount of time, it no longer stays with the input, and continues to rise on its own, seemingly getting faster and faster, forevermore...

[Simion32]

"Buffered Input Read Count" seems to be rather unusual. The value starts rather low, and does not immediately rise when using the inputs. After a few seconds it begins to rise whenever I do something, e.g. when the mouse is moved. It continues to rise alongside mouse movements. After a certain amount of time, it no longer stays with the input, and continues to rise on its own, seemingly getting faster and faster, forevermore...

This.

The expected behavior is that only devices with high amounts of input will trigger an extra buffer read (you read the first message, and then check the buffer to retrieve more if there is any more). Normally keyboard key presses and gamepad button presses will not trigger an increment of that counter.

It SHOULD be following the input, but apparently something goes wacko after a few seconds. It shouldn't be picking up extraneous input from nowhere and at an ever-climbing rate.

Also, there should be practically ZERO mouse delay. The mouse may become slower yes, but there should be NO delay happening.

This is going to be a real pain to fix, especially since I now have absolutely no lead at all as to what is going on.

I've done all the buffering and preemptive input collection I can. Also, the input spools EACH hold 8 times what they did before: 16384 input records per frame - and I highly doubt your mouse is pushing updates at a blinding 983,040Hz...

It seems as if the mouse triggers some sort of internal switch that continually sends updates, but now, I really don't understand how there could be so much input coming in that it can clog up the windows message loop.

EDIT: I'm going to attach a device identifier to the last device detected, and display that. It might provide some clue, hopefully.

[Simion32]

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

>>> DOWNLOAD LATEST VERSION HERE <<<

• Extended Input Debugging Outputs for Kingizor

[Simion32]

Bug Update: Kingizor's issue was due to the game controller he was using, which was apparently a cheap imported device.

The extreme lag happened because the controller always sent updates no matter what was being done -- and at a very high rate -- which piled up a mountain of WM_INPUT messages on the Windows messaging queue (which is processed one message at a time).

DELTA was sitting there processing the messages as fast as it could, even taking multiple extra WM_INPUT's at a time; and to no avail, because in this case the queue still filled up faster than DELTA could empty it.

I might look into TRYING to make some sort of workaround for this type of problem, but my options are very limited, as the Windows message loop cannot be changed all that much without causing weird behavior or single-core-related threading glitches.

[Simion32]

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

>>> DOWNLOAD LATEST VERSION HERE <<<

The real issue Kingizor exposed has been found: An initialization bug in CInputDevice was causing constant allocation and sorting of fake "detected input devices" when there should only have been exactly one allocation per device.

For anyone that tests: For DELTA to pass the test for this bug, you must make the "Input Message Count" surpass a value of 4444 without any input lag occurring. Also, the "Number of Detected Devices" should not sporadically go up. It should only go up by 1 when you first press or move a device.

EDIT: Re-uploaded with fix to an exit crash (due to input when buffer is gone).

[Simion32]

Progress Update: Tab Control is Underway!!

DELTAv006B_TabControlFirstGraphics.png (6.72 KiB) Viewed 161539 times

Note: The names used in the tabs in this example image are just for testing the multiple-rows code.

And yes, it does support an arbitrarily large amount of tab rows.

[Simion32]

Update: Controls Configuration Dialog in Progress

I'm also working on button and controller graphics to put in the dialog, here's an awesome SNES controller replica sprite I just completed:

The controller we all know and love, now in 2D!
I did both retro colored and logo colored buttons.

Simion32_SNESController.png (28.06 KiB) Viewed 161502 times

[Markster]

I got more questions about Delta and DKCLB.
----------
1. How fast would custom objects and game data load at USB 2.0 speed? (Like running it off a USB flash drive for an example.)
2. How would Delta run and look on a HDMI cable with 720p enabled?
3. Would Delta work with Wine and Ubuntu?

[Simion32]

Those are some very unique questions. Let's see...

(1) Don't run DELTA off of a flash drive, period. It's too slow. Though DELTA itself might still load fast, loading levels would be extremely sluggish. You need to use a hard drive. Treat DELTA like you would a large game install like Sim City 4, because although it is low in file size, the engine is equally as demanding of your computer's resources.

(2) Computer monitors have higher definition than TVs, and are often clearer, but I presume DELTA would look just fine if you were able to get the cords and etc. set up. I'm not all too sure about the TV's Hz, though, which might (not sure) introduce timing issues.

(3) I haven't taken any time to try this, but DELTA is probably better off being adapted to Linux instead of running through Wine. Also, I've never managed to fully install Ubuntu, even just through the live disc. It's too damn confusing.

[Simion32]

Progress Update: Dialog still undergoing renovation.

I have the basic dialog up and running, and it can configure buttons and devices and so forth.

It still needs work before it is good enough for public release, but here's a small teaser:

ControlsConfigTeaser.png (12.79 KiB) Viewed 161418 times

About the XDQ extension; it comes from random programming jargon I came up with and means essentially nothing. I'm not going to change it, so don't ask.

[Simion32]

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

>>> DOWNLOAD LATEST VERSION HERE <<<

• Input Configuration Dialog with 8 Players!
• Ability to configure global key commands
• Can no longer open two instances of DELTA from the same folder.
• Printscreen and Alt+Printscreen Functions

I've added some details to the readme.html for those who are lost trying to test.

[Markster]

Awesome!

Keep up the good work.
----------
And some more questions.

1. Will you make it where you can compile Delta game data, like custom objects, music, etc. into one Delta game file, or will you have to make separate folders for data?

[Simion32]

You'll have to design it with separate folders, but there is going to be a "conglomerate custom stuff and game" kind of file.

The file extension for this is still being thought out but it will probably be the (*.DKC) extension.

[WAZ__Up]

I dont get it, why does the config have 2 controllers, and why does one of them look like a ps2/game cube hybrid?

[Simion32]

Because they are virtual buttons. The names of the buttons are intended to represent the names of the buttons from all the Nintendo controllers up to Wii, and the PSX buttons are there too, just to be sure I caught most of the buttons.

DELTA_Buttons.png (35.82 KiB) Viewed 161319 times

The buttons above the modified SNES controller are the ones I couldn't fit anywhere else.

This is for those who want to design custom objects around a different controller. I had to have SOME kind of image for them to start with. If you want separate controller images, you'll have to wait because drawing this pixel art takes time, you know.

[Markster]

Awesome, and my favorite part about it is... 8 PLAYERS!!!
Unlike 2 players like the original DKC, and I got more questions about Delta.
----------
1. I heard that you will fix the physics of Winky, will you keep the original physics too?
2. How good would delta run at 320x240? (Which is the resolution I want to make my games in.)
3. Will synonymously playing be possible? kinda like DKC Returns or NSMB Wii.