> > I'm afraid it is windows only. Linux is black screen and refuses to > > report key presses.
> Very intriguing game, as expected ;) > Also I have a few technical issues with it. Some might be libtcod > bugs... : > * first it uses 100% cpu. Are you limiting the framerate with > TCODSystem::setFps ? I don't know how it can fit in the multi-threaded > architecture, though.
No, I am not limiting the frame rate, so the main display thread will happily do 100%. However, I had found with another project that if you have another thread at 100% and try to limit the display thread you seem to start missing keystrokes. I never did try this with this project, so it may or may not be effective.
The real killer, however, is the flames. There are two threads running and it is quite likely they don't get their job done within the 20ms allotted, so they will each be 100%.
> * jacob.cfg doesn't seem to be taken into account. I changed the > flames height and tried to set windowed mode but the game it doesn't > do anything.
Darn... Yes, I can reproduce this with the version I download from the website. I am very confused as it worked just fine when I tested it, I wonder if I broke something at the last moment?
Changing the flame size does work. Note that it does not change the size on screen, it changes the size of the simulation that is then sampled to draw on the screen. If you set it to 0, for example, you should get the bars.
> Also I can't switch to windowed mode while in game. The P > shortcut only make the screen blink once, but it stays fullscreen.
This also doesn't work with the downloaded version, but worked when I tested. I'm just invoking TCODConsole::setFullScreen() here...
> I still have to dig it, though, because I didn't figure out everything > and I don't know (or rather don't remember) what a jacobian is... ;)
> > > I'm afraid it is windows only. Linux is black screen and refuses to > > > report key presses.
> > Very intriguing game, as expected ;) > > Also I have a few technical issues with it. Some might be libtcod > > bugs... : > > * first it uses 100% cpu. Are you limiting the framerate with > > TCODSystem::setFps ? I don't know how it can fit in the multi-threaded > > architecture, though.
> No, I am not limiting the frame rate, so the main display thread will > happily do 100%. However, I had found with another project that if > you have another thread at 100% and try to limit the display thread > you seem to start missing keystrokes. I never did try this with this > project, so it may or may not be effective.
> The real killer, however, is the flames. There are two threads > running and it is quite likely they don't get their job done within > the 20ms allotted, so they will each be 100%.
> > * jacob.cfg doesn't seem to be taken into account. I changed the > > flames height and tried to set windowed mode but the game it doesn't > > do anything.
> Darn... Yes, I can reproduce this with the version I download from > the website. I am very confused as it worked just fine when I tested > it, I wonder if I broke something at the last moment?
It seems to only show up on the optimized build. However, I think the serious clue is that I couldn't pass bool down in the first place. Check this code out:
// The logical thing to do would be to pass fullscreen into here. // But for reasons I cannot fathom, if I do that it always goes // full screen even if it is false! Bah. TCODConsole::initRoot(SCR_WIDTH, SCR_HEIGHT, "Jacob's Matrix", false); 0040B88F xor ebp,ebp 0040B891 push ebp 0040B892 push offset string "Jacob's Matrix" (41B3F0h) 0040B897 push 32h 0040B899 push 50h 0040B89B mov byte ptr [esp+38h],cl 0040B89F call dword ptr [__imp_TCODConsole::initRoot (4191F0h)] TCODConsole::setFullscreen(fullscreen); 0040B8A5 mov edx,dword ptr [esp+38h] 0040B8A9 push edx 0040B8AA call dword ptr [__imp_TCODConsole::setFullscreen (4191F4h)] 0040B8B0 add esp,14h
You will note that we use cl to store the bool value, suggesting a short-enum world. When we call setFullscreen we push dword ptr [esp +38h], of which only the lower byte is 0. If the callee is living in a full-enum world, the bool enum will be 32 bits, so all the extra crap will cause it to believe that it should be full screen, regardless of what the lower 8 bits are. I'm trying to find out how you built it but I can't find your Makefile/.sln files in the tarball I have.
Ah... Solved it myself...
The built in C++ bool is a char. This is used in my code, as it is C+ +. libtcod uses an enum { false, true } which, if -fno-short-enums is set, or in the MSVC world where enums are allows large, will be an integer. So the MSVC code generator is pushing a bool onto the stack as that is what TCODConsole::setFullScreen() wants, but then TCODConsole::setFullscreen() is reading an int off the stack since it thinks bool is an integer and much zaniness ensues.
Now hopefully I haven't called too many functions that use a bool... -- Jeff Lait (POWDER: http://www.zincland.com/powder)
> > > > I'm afraid it is windows only. Linux is black screen and refuses to > > > > report key presses.
> > > Very intriguing game, as expected ;) > > > Also I have a few technical issues with it. Some might be libtcod > > > bugs... : > > > * first it uses 100% cpu. Are you limiting the framerate with > > > TCODSystem::setFps ? I don't know how it can fit in the multi-threaded > > > architecture, though.
> > No, I am not limiting the frame rate, so the main display thread will > > happily do 100%. However, I had found with another project that if > > you have another thread at 100% and try to limit the display thread > > you seem to start missing keystrokes. I never did try this with this > > project, so it may or may not be effective.
> > The real killer, however, is the flames. There are two threads > > running and it is quite likely they don't get their job done within > > the 20ms allotted, so they will each be 100%.
> > > * jacob.cfg doesn't seem to be taken into account. I changed the > > > flames height and tried to set windowed mode but the game it doesn't > > > do anything.
> > Darn... Yes, I can reproduce this with the version I download from > > the website. I am very confused as it worked just fine when I tested > > it, I wonder if I broke something at the last moment?
> Ah... Solved it myself...
> The built in C++ bool is a char. This is used in my code, as it is C+ > +. libtcod uses an enum { false, true } which, if -fno-short-enums is > set, or in the MSVC world where enums are allows large, will be an > integer. So the MSVC code generator is pushing a bool onto the stack > as that is what TCODConsole::setFullScreen() wants, but then > TCODConsole::setFullscreen() is reading an int off the stack since it > thinks bool is an integer and much zaniness ensues.
Okay, I managed to build a work around. I had to basically only ever call the libtcod functions with a constant false or true, only then would the compiler be lazy enough to not bother to leave the stack undefined. It actually went out of its way to undefine the stack if I, for example, just called with an int rather than a bool.
Please fix your C-style bools! They must be char, not int, to match C+ +. Or get rid of bool from the C++ interface. -- Jeff Lait (POWDER:http://www.zincland.com/powder)
> Thank you, very glad to hear it ran for you. What level did you get > to?
I only made it to level two. This is definitely a keeper though, so I'll be trying it again. -- Rick Clark Clark Productions: http://rickclark58.googlepages.com/
> I'm afraid it is windows only. Linux is black screen and refuses to > report key presses.
Looks cool, though can be a little confusing to play. Suppose I'll get the hang of it eventually...
One weird bug though - after quitting it's turned my cursor into some... thing. Looks like a column of 6 little arrows. Screenshot doesn't work in capturing it... Dunno what the hell's going on, but it's weird. Was running it in Windows mode and the cursor had changed when I exitted the game (which should be easier by the way). Restart will fix it I'm sure.
By the way, game runs at a steady 75 or so on my quad core. Runs perfectly fast, and the looks are worth it :)
> > I'm afraid it is windows only. Linux is black screen and refuses to > > report key presses.
> Looks cool, though can be a little confusing to play. Suppose I'll > get the hang of it eventually...
It does twist your mind. Last night I dreamed of coloured dungeons :>
> One weird bug though - after quitting it's turned my cursor into > some... thing. Looks like a column of 6 little arrows. Screenshot > doesn't work in capturing it... Dunno what the hell's going on, but > it's weird. Was running it in Windows mode and the cursor had changed > when I exitted the game (which should be easier by the way). Restart > will fix it I'm sure.
Worrying. There is some funkiness because both I and libtcod grab SDL, and I think libtcod does an atexit() SDLshutdown which crashes if I don't also pre-shutdown...
> By the way, game runs at a steady 75 or so on my quad core. Runs > perfectly fast, and the looks are worth it :)
Jeff Lait wrote: >> The built in C++ bool is a char. This is used in my code, as it is C+ >> +. libtcod uses an enum { false, true } which, if -fno-short-enums is >> set, or in the MSVC world where enums are allows large, will be an >> integer. So the MSVC code generator is pushing a bool onto the stack >> as that is what TCODConsole::setFullScreen() wants, but then >> TCODConsole::setFullscreen() is reading an int off the stack since it >> thinks bool is an integer and much zaniness ensues.
> Okay, I managed to build a work around. I had to basically only ever > call the libtcod functions with a constant false or true, only then > would the compiler be lazy enough to not bother to leave the stack > undefined. It actually went out of its way to undefine the stack if > I, for example, just called with an int rather than a bool.
> Please fix your C-style bools! They must be char, not int, to match C+ > +. Or get rid of bool from the C++ interface.
sizeof(bool) in C++ is implementation defined, and I've certainly seen compilers with sizeof(bool) == sizeof(int).
To solve this properly, it's important not to confuse the C++ compiler into thinking "C++ bool" where libtcod actually means a user-defined type. Renaming the libtcod type would be the cleanest solution to achieve this.
> Jeff Lait wrote: > >> The built in C++ bool is a char. This is used in my code, as it is C+ > >> +. libtcod uses an enum { false, true } which, if -fno-short-enums is > >> set, or in the MSVC world where enums are allows large, will be an > >> integer. So the MSVC code generator is pushing a bool onto the stack > >> as that is what TCODConsole::setFullScreen() wants, but then > >> TCODConsole::setFullscreen() is reading an int off the stack since it > >> thinks bool is an integer and much zaniness ensues.
> > Okay, I managed to build a work around. I had to basically only ever > > call the libtcod functions with a constant false or true, only then > > would the compiler be lazy enough to not bother to leave the stack > > undefined. It actually went out of its way to undefine the stack if > > I, for example, just called with an int rather than a bool.
> > Please fix your C-style bools! They must be char, not int, to match C+ > > +. Or get rid of bool from the C++ interface.
> sizeof(bool) in C++ is implementation defined, and I've certainly seen > compilers with sizeof(bool) == sizeof(int).
> To solve this properly, it's important not to confuse the C++ compiler > into thinking "C++ bool" where libtcod actually means a user-defined > type. Renaming the libtcod type would be the cleanest solution to > achieve this.
Maybe the cleanest, but not the most handy for the end user. Imagine mixing TCODBool, SDLBool, FMODBool, WhateverBool... The best for libtcod is to make bool work without complications. I already spotted this issue some time ago and fixed it in a few places but not everywhere. By the way, it happens only with Visual Studio...
> > > > > I'm afraid it is windows only. Linux is black screen and refuses to > > > > > report key presses.
> > > > Very intriguing game, as expected ;) > > > > Also I have a few technical issues with it. Some might be libtcod > > > > bugs... : > > > > * first it uses 100% cpu. Are you limiting the framerate with > > > > TCODSystem::setFps ? I don't know how it can fit in the multi-threaded > > > > architecture, though.
> > > No, I am not limiting the frame rate, so the main display thread will > > > happily do 100%. However, I had found with another project that if > > > you have another thread at 100% and try to limit the display thread > > > you seem to start missing keystrokes. I never did try this with this > > > project, so it may or may not be effective.
> > > The real killer, however, is the flames. There are two threads > > > running and it is quite likely they don't get their job done within > > > the 20ms allotted, so they will each be 100%.
> > > > * jacob.cfg doesn't seem to be taken into account. I changed the > > > > flames height and tried to set windowed mode but the game it doesn't > > > > do anything.
> > > Darn... Yes, I can reproduce this with the version I download from > > > the website. I am very confused as it worked just fine when I tested > > > it, I wonder if I broke something at the last moment?
> > Ah... Solved it myself...
> > The built in C++ bool is a char. This is used in my code, as it is C+ > > +. libtcod uses an enum { false, true } which, if -fno-short-enums is > > set, or in the MSVC world where enums are allows large, will be an > > integer. So the MSVC code generator is pushing a bool onto the stack > > as that is what TCODConsole::setFullScreen() wants, but then > > TCODConsole::setFullscreen() is reading an int off the stack since it > > thinks bool is an integer and much zaniness ensues.
> Okay, I managed to build a work around. I had to basically only ever > call the libtcod functions with a constant false or true, only then > would the compiler be lazy enough to not bother to leave the stack > undefined. It actually went out of its way to undefine the stack if > I, for example, just called with an int rather than a bool.
> Please fix your C-style bools! They must be char, not int, to match C+ > +. Or get rid of bool from the C++ interface.
The enum is not used for C++. It's enclosed in ifndef __cplusplus. So with C++, it uses directly the C++ bool. Since both the call to setFullscreen in your code and setFullscreen implementation in libtcod have been compiled with MSVC, they use the same bool definition. The problem occurs when the C++ wrappers calls the C implementation, which uses the enum. I think replacing bool by int is the C prototypes when the .h are included by a C++ file will make everything work smoothly. To be fixed in final 1.4.1...
Tried to compile it on MacOSX. After a few tweaks I successfully compiled and linked it. But it is crashing somewhere deep down in libtcod :( I got compiled osx version 1.4.1rc3 from site...
