next »

[GekidoRising]

Short version:

I made a 2D graphics engine and I have barely any idea how well it runs on other computers. It would be super awesome if you could download it (link below), run it, then tell me if it launched or died.

Description:

Hi there! I've been working on a custom graphics engine for my game for about 8 months called FIRE2D. It is programmed in C++ using GLFW 3, GLM, tinyxml2, dirent, stbimage and FMOD. I've gotten it to a state where it's pretty much as complete as it's going to get seeing as I've shifted all of my focus towards the game engine itself. That isn't to say that I've completely dropped FIRE2D though, but rather, I'll only be making additions to it based on what the game requires instead of just going willy nilly over features.

Seeing as I'm still relatively new to this with only 4 years C++ experience and next to no experience in the industry itself, I'm really just curious if the program launches at all. That said, I've tested this on a few of my friend's computers with varying results. Recently, they have been more promising seeing as before, the engine almost never launched on other computers, but that was because of some bad shader variable names which for some reason, worked perfectly fine on only this computer, and I'm pretty sure I've fixed those by now.

So, if you could download the demo, run it and then tell me what happened, I would be perfectly fine with just that. I also included a few demonstrations of the more advanced features of the engine as well as a quick demo of how the game engine looks so far so if you want, you can take a look at those too, but mostly, I'm just curious whether the engine runs at all!

Changes:

v1.00:
-Initial release

v1.01:
-Added error logging for crashes on startup
-Fixed stack overflow crashes (which are, unfortunately, indicative of other crashes)
-Increased the likelihood of the game launching

Known issues:

msvcp110.dll is missing!
Your need the C++ 2012 VS redistributable to run the engine. You can download it here.

Particle effects don't render
I'm the one who caught this error when someone at an indie get together I went to let me run the demo on their computer. I have to admit, I'm not sure what's up with this one but I didn't get the chance to ask him what specs he was running on his laptop. If anything, this is probably indicative of the fact that I should really implement some glGetError logging.

Just give me the demo:

Requirements:

• The Visual Studio 2012 C++ Redistributable Update 4 (download here).
• An OpenGL 3.2 compatible graphics card

Download here: https://dl.dropboxusercontent.com/u/21521620/FIRE2D%20Demo%20v1.01.zip

Instructions:

1)Extract folder anywhere
2)Go into Release folder
3)Run Epicenter.exe

3a) It crashed!
4)Darn! Oh well, part of the fun I guess! In the same folder as the exe, there should be a errorLog.txt. Send me the contents either here or in a PM if you don't mind.

3b) It launched!
4)Cool! :D

Stats:

Number of computers:
Successfully launched on: 4
Launched with bugs: 1
Instant crash: 1

Screenshots:





Thanks:

While I technically have been a member for a few months now, I am still a relatively new poster. I've been a bit shy for posting lately as I've been trying a little too hard to think of ultra meaningful posts, but I really do have the intention to be more active in conversations around here. What I'm getting at is, I really do appreciate your time quite a lot especially because I have not much contributed much in return!

Ah well, perhaps now is a good opportunity to change that!

Again, thank you very much!

[Quicksand-S]

Crashed instantly. Fault module name was one of the ms-something DLLs.

The second time I tried running it, in order to get the full filename of the DLL, it was different. ntdll.dll crashed instead. (For me, this seems to be most commonly listed fault module when it comes to this engine.)

I tried again, because I was curious, and this time it just named "Epicenter.exe" in the crash window.

[GekidoRising]

Hmm, the ms-something dll might have to do with the msvcp110.dll which I mentioned in the known issues, but if that's the case, it would have said that the DLL is missing and not that it's a fault module (unless it being a fault module actually means that the dll was missing).

As for ntdll.dll being the fault module instead, after doing a bit of research, this looks a lot more terrifying to figure out what could be causing this error as it seems like it could be caused by a whole host of things. There is a small chance though that this error is popping up BECAUSE the ms-something dll error popped up before. I'm not entirely sure.

Thanks for the reply though! It's awesome to get this caught now and not a few months down the line when I'm already in too deep.

[Quicksand-S]

Yeah, it would've told me it was missing. My understanding is that the "fault module" is whatever module tried to run something and crashed, so the DLL was found and just didn't work. Anyway, I just double-checked and I do in fact have that DLL in my System32 folder.

[GekidoRising]

Hmm, good to know. Anyway, thanks for the effort! I'll probably just be reusing this thread in the future any time I update the demo, so hopefully I can either find a system that has the same issue as yours or the issue will get resolved over time as I learn more about C++!

Thanks for the help!

[Quicksand-S]

It looks like no matter which module is mentioned, it's always a "c00000fd" exception. As far as I can tell, that's a stack overflow error. You should be able to find a lot of info online about avoiding such errors, if that is actually the issue here.

[GekidoRising]

Just a heads up, thank you so much for doing the research on this because it being a stack overflow error actually really narrows it down! Fortunate for me, 95% of all of the stack overflow errors come from the same method in my engine, so it was super easy to track down the issue!

The bad news is, the method that's causing these stack overflows is ironically the error reporter I made for my engine, haha. What's happening is something engine critical breaks, so it reports an error but in attempting to create a textbox, an error occurs so it tries to report that error, create a text box, breaks, reports error, breaks, reports error, breaks, ect ect ect until the engine dies.

Seems like it was high time to change that so I changed my error reporting system to not just infinitely report errors that IT generated. Unfortunately, this doesn't mean the issue is fixed as, it being the error reporter, it means it died trying to report an error in OpenGL instead. So for that, I implemented error logging so that it just outputs errors into a file instead of trying to convey them through the game which is dying before that ever gets to happen!

No obligations but if you're up for still helping out, I updated the link with my changes in the OP and added some instructions for the error logging. Either way, thanks a lot for your patience and help with this, Quicksand :D

[Quicksand-S]

Glad you managed to track that down. An error with the error reporting? Funny how good additions to a program can backfire like that.

I'm not sure what the original error was because it's working perfectly for me.

Are you using different settings for the Post Processing fire than for the other fires? That one seems so unrealistically energetic, whereas the other ones seem to have much slower particles. I prefer the slower ones by far.

Anyway, I get a solid 60fps with the Ctrl-Shift-P recursive particle test or with the maximum number of entities in the Game Engine room.

Speaking of the game, that was my least favorite part of the demo. I found the top speed and the acceleration both too slow for my tastes. The walking animations were nice, though.

The highlight had to be the fire effects on the various animated shapes. Really nice stuff.

[GekidoRising]

Oh wonderful! What a relief haha! That's somewhat puzzling though as I didn't actually change any OpenGL stuff, I only changed the order they were loaded in. Chances are you might still have an errorLog.txt generated with the game, but if not, then that is very weird but hey, I'll take it!

As for the post processing, if you're referring to the bloom, I'm pretty sure my bloom calculation is just straight up wrong. It doesn't look nearly the same as it does in that one tutorial I followed so in the future, I'm gonna have to put some research in a proper bloom effect. For now though, I'll just refer to it as my weird glowy effect, haha.

Happy that you're getting 60fps on all accounts! As for the walk speed thing, I agree, lol. I probably should beef them up a bit so I could at least speed up testing!

All in all, thanks for your patience with this, the help is really appreciated!

[Quicksand-S]

As for the post processing, if you're referring to the bloom, I'm pretty sure my bloom calculation is just straight up wrong.

I'm referring the the speed of the particles in that demo. The look as though they're created more often and move upward faster than in most of the other fires. I compared the speed of the "H Key" one to the fire on the Post Processing screen and they seem completely different in terms of speed. To me, the Post Processing one just looks much too fast to be natural, even for an energetic fire.

Oh and there's no error log in the game folder. Is that where it would be, if one had been created?

[GekidoRising]

Oooooooh, okay, I know what you mean now. Yes, the two effects are indeed two different effects and holy moly, they are indeed very different speeds as well as very different emission rates (the post processing effect fire is 5x faster and emits twice as many particles). On top of that, it seems I set the flame size to min="6" max="2"

I just spent a little while toiling with it and it looks a little bit calmer now. I'll have it in next time I update tech demo since it isn't really engine critical!



As for the error log, it should be in the same folder as the exe. If there's nothing there then cool!

[tgramsus]

I get the following error when trying to run it in a Win 7 machine:

WGL: A forward compatible OpenGL context requested but WGL_ARB_create_context is unavailable

It has OpenGL version 2.1, so probably that's why I get the error.

[GekidoRising]

Oh yeah, I should probably specify that a minimum of OpenGL 3.2 is required. Sorry, my mistake!

It would be cool to go back and see what happens but I'm actually making use of the OpenGL contexts and GLFW 3 can't go below OpenGL 3.2 anyway.