Yamgine»Blog

7DRL Complete! - "Going Ham" Demo

Hey guys,

It's been a little while, but I've been very busy with the engine project. My friend and I were able to complete our 7DRL game mentioned in the last blog post, with the working title "Going Ham". You can find a download for the demo here.

I'm pretty happy with how it came out. The general consensus I've gathered is that its difficult, but fun. Best of all, no one has reported any technical mishaps!

Since my last post I've added two new "engine" features, being SDF text rendering, and stack trace dumps when the app crashes. I'm using a library for the SDF generation, which can be found here. The stack trace dumps are being generated through the Win32 API, using StackWalk64. The documentation on using this is pretty bad, so if anyone wants to add similar functionality to their app, I'd recommend checking out my source code.

Here's how the pause menu is coming along. All of the rendering is in absolute coordinates right now, so in a range between (0,0) and (1920,1080).


This demo was a good way to really "kick the tires" on the engine. It has become obvious to me that much of the existing systems need some work to better accommodate a larger number of objects, scaling from 20 objects to 200 objects. The editor still has a ways to go to be nice to use. The lack of undo functionality or multi-select editing became really painful as the scene got larger. Adding on a single room with this editor would probably take someone half an hour... I've been considering trying to add a BSP sort of level editor, like Hammer and UE4. Honestly, its overwhelming, the amount of work that has to happen to start really making traction on this FPS project.

You can find the devlog video reviewing all of this here.
Simon Anciaux,
I just tested it and it's not running that well on my machine (i7 860, Radeon R9 280, 8GB of RAM) on 1080p windowed with vsync (I didn't find how to open the option menu). It never goes above 30 fps and I get small (sometime not that small) freezes every few seconds. I tried resizing the window but it still runs the same. Overall it feels laggy.

I recorded a short video if you want to look (there are some artifacts due to the recording). At 20sec in the video you can see a huge slowdown. But the video is pretty representative of how it runs in general.

I also think the application closed itself twice (I don't think it crashed since I didn't get the windows message that an application crashed). I think it might be related to minimizing the windows.

It would also be a good idea to restore the visibility and movements of the mouse cursor if the windows doesn't have the focus.

And one last thing, I use an azerty keyboard layout so I need to switch keyboard layout (Alt + Shift) to play. You may want to take a look at this post for a way to avoid that.

Good luck !

Yam
James Fulop,
Thanks for testing it! I will try to get it working better for you.

The demo included doesn't have the options menu, that is something new I'm working on.

The physics kinda implodes if it takes longer to compute the physics step than the simulation time allotted for that step. So on my PC I'm running dangerously close to that line, average CPU time to calculate a physics step is around 7ms on this build (lame...), while the step is covering 11ms of game time. A constant catch-up kind of cycle can happen. So you are having extra trouble around that 20 second mark because I am simulating the player plus those 3 cube chasers.

I disabled the "app crashed" dialog because its kind of silly, it's not a helpful dialog, but it seems like that is causing more confusion than it's worth so I will re-enable it until I can come up with a better solution.

I hadn't considered the AZERTY keyboard problem yet, your reference post looks like a great resource on the topic, thanks.