PixelBots Combat Prototype 1
Max Savenkov

1. About the game.

For a long time, I've been a big fan of Kris Asick's PixelShips games. The whole idea of collecting something appeals to me a lot, and his projects had all the right ingredients. I always wanted to make my own game in the same vein, but without blatantly copying ideas. PixelBots (working title) is this game.

Despite sharing the idea of "gotta catch 'em all" with PixelShips, PixelBots is different in almost everything else. Rather, it's PixelShips meet X-Com meet Rogue (with maybe a dash of Quazatron). The focus of the game is tactical combat in randomly generated levels, where your team of bots will battle various enemies as they descend to the lowest level of old military installation. You will be able to capture enemy bots to supplement your collection. Each robot have different combination of basic parameters, weapons and abilities. And because I can't even make a Breakout clone without adding a storyline, there will be messages appearing here and there, through which you will be able to discover the past of your hero.

2. About this release.

Current release is not a complete game. It's not even an early alpha. Rather, it's a prototype of combat system. It has no other features beyond simple level generation, combats and some AI.

You can download it here: Pixelbots Downloads

Here's what's in:

    Video & Screenshots:




    Title screen and some options:

    Your bots at the start of level:

    Some enemies! We can't fry them, though, because the line of fire is blocked by wall. There is no fog of war or visibility calculations, as you can see.

    Now this feller is about to get a load of laser blasts in his ugly bot face!

    Somewhat worse for the wear, but still alive. One of the bots have a Forcefiedl on.

    Green bot is the boss. He is not very hard, because he don't have special AI yet and can't use abilities.

    "Trooper" bot is about to use "Grenade" ability.

    3. Bugs.

    Since it's a prototype, this release may contain a lot of bugs. If you report them, I will try to fix them, but at this point I mostly care only about game-breakers.

    Known bugs:

      4. Feedback.

      I would greatly appreciate all feedback, because I want to make sure the combat system is interesting enough before moving forward. Post or send your ideas and suggestions!

      If the game crashed, it will try to send me a crash report. Please allow it to do so, this way I might be able to find and fix important bugs sooner.

      Also, please allow the game to send statistic to my server. It will allow me to get a picture of how people are playing this prototype. The game will not collect or send any personal data or identifying information about you, or your computer.

      Edgar Reynaldo

      Due to the size of the window the game is virtually unplayable. There are at least two buttons off screen, and the bottom of the window is off screen so I can't scroll down with the mouse, and I also don't know how to attack. I figured out how to move at least. My native resolution is 1280x800 fwiw.

      Max Savenkov

      Ah, that seems to be a problem. UI and window size is really not adaptable. 1024x768 is a minimum :( Let's see if I can hack resolution selection and scaling into that code quickly...

      Edgar Reynaldo

      I can set 1024x768 fullscreen okay, and that would work then.

      Max Savenkov

      Allegro crashes when I try to run in fullscreen 0_o in alloc_glyph_region.

            data->page_lr = al_lock_bitmap_region(page,
               data->lock_rect.x, data->lock_rect.y,
               data->lock_rect.w, data->lock_rect.h,
            /* Clear the data so we don't get garbage when using filtering
             * FIXME We could clear just the border but I'm not convinced that
             * would be faster (yet)
            ptr = data->page_lr->data;

      al_lock_bitmap_region seems to be returning 0 and nobody checks return value before accessing it.

      Maybe something is wrong with my build of Allegro, though, like an old version of Freetype... I mean, page_lr should probably be checked before use anyway, but why is it returning 0 in fullscreen mode only?!

      Otherwise, the most obvious reason is that format is wrong.

      EDIT: I'm not alone with this: https://www.allegro.cc/forums/thread/612544 Will try OpenGL now.

      EDIT2: OK, Fullscreen checkbox added, using OpenGL now, and also you can quit game even from main menu/title screen :) Archive updated.

      Mark Oates

      I played it, it's playable. I had no crashes or bugs, but didn't make it all the way through. I lost to a Warrior, but it was fun. :)

      The first thing I noticed is when a craft moves, the camera follows. I'd just keep the camera in the same spot because it was a little bit disorienting.

      Max Savenkov

      The first thing I noticed is when a craft moves, the camera follows. I'd just keep the camera in the same spot because it was a little bit disorienting.

      It saves some scrolling, though :) If enough people complain, I might make it an option, or remove it completely.


      Maybe scrolling to keep it on screen but not orienting the camera on it.

      Edgar Reynaldo

      Your latest version crashed for me. I was going to send the error report, but you need to run my default email client to send it? No thanks, and it kind of pisses me off that you are taking a screenshot of my desktop. Who knows what I could have been working on?

      Max Savenkov

      Hm, not it should not run your e-mail client! Also, it's not a screenshot of your desktop, but just game window. Maybe I should name screenshot file to reflect that.

      Edgar Reynaldo

      Well in this case the game crashed before the window was ever drawn to, so it still had my desktop in the window buffer.

      Max Savenkov

      I didn't know it could do this. I mean, take screenshot of desktop instead of game... It's a stupid behaviour and not helpful at all. I guess I'll have to disable screenshot feature of crash reporter then. I'm sorry.

      Could you please send me a dmp file of crash manually then?

      EDIT: Updated version with screenshots disabled. Also, it definitely should only try to send report itself now, without using external programs.

      Edgar Reynaldo

      It'll take me a while to download it again, like 1/2 hour or so, but I can post the files it said it was going to send for you.


      I don't know where to find these two files though :


      Max Savenkov

      OK, I see. Allegro can't create 1024x768 window. I guess whether it works or not depends on where Windows tries to position it. If it overlaps with screen's edges, it will crash.

      I'm sorry, but I guess you can lay my game aside for a while :( Until I implement resolution detection at start and proper resizing for UI elements and input (I tried to hack it in yesterday, but it proved to be not so simple).

      Edgar Reynaldo

      The simplest solution might be to change the size of your playing area and keep the rest of it as fixed as possible. I'll keep an eye on this thread.

      Max Savenkov

      Thank you for your patience! I'll try to fix this in a couple of days.

      EDIT: OK, here's a new version. It's still a hack, but it should get the game to run on smaller screens until I can rewrite GUI code to handle different resolutions without scaling the whole picture.

      The operating procedure is now this:

      1) On start, the game will check if desktop resolution is too small to run 1024x768 window. If it is, it will run 800x600 window with scaling instead. Because of downscaling, it will look blurry.

      2) You can run the game in windowed mode, but if you chose Fullscreen option, it will try to switch to 1024x768 to avoid downscaling (it's really ugly).

      On somewhat unrelated note, I now support the crusade to make laptop/netbook screens support larger resolutions :)

      P.S. My server tells me 5 people played my game (with statistic sending enabled), and 4 of them won it on the first try. Is... Is it a representative sample? :) (I know there are a lot of folks who disable stats reporting, though, so the actual number might be closer to 20 players)

      Edgar Reynaldo

      It still crashes and doesn't show the selection screen. It does show an empty 800x600 window though. I tried to send the report but it kept saying socket connection error and it tried like 6 different IMAP servers, and then it asked me to send it with my default mail program at which point I closed it.

      Max Savenkov

      OK, let's try this then: if you click on "What does this report contains?" it'll show list of files and Export button. Export will save report file in chosen location. Could you then attach it here (it should be small, about 10-20Kb)?

      Trent Gamblin

      Max, did you develop some kind of crash reporter for this game? Could you tell us about it?

      Edgar Reynaldo
      Max Savenkov

      Trent, no, I didn't develop it. I just used quite well-known CrashRpt library. It only works under Windows, and now it seems it does not do a very good job.

      I actually was going to use Google's BreakPad crash reporter (since it at least is multi-platform), but when I encountered gyp project generator they use instead of CMake, I decided to put it away for a while, because I didn't have the right combination of Python libraries for it to work.

      Trent Gamblin

      Ok, thanks for the info.

      Max Savenkov

      Edgar, wow, that didn't help at all :) The stack seems to be completely smashed, there is only one address on it, and even crash reporter was unable to associate any module with it.

      I have compiled a version with some debug logging added for you. Let's see if we can get anything from it:


      Also, in this version crash reporting is disabled. In Vista and Win7 you can create a memory dump of running (or crashed) process through Task Manager. Please, post here text from deubg console (which now should be shown along with main window) and dump created with Task Manager, if possible.


      I played it and I quite like it, but I am a fan of these games. Definitely reminded me of Laser Squad in terms of the game play.
      It seemed quite stable for me, although I didn't quite manage to finish the level, I will be keeping an eye on your game. It also provided me with some inspiration for my own game.
      Keep up the great work.


      Looks like a good start. Kudos on putting the robot stats in text files. By the way, the stats look like the ones from Zoids Legacy on the GBA, which allowed an amazing level of customization of the units. But I'm not sure how it fares when the robots have only their built-in abilities/weapons. (ie. often have only one way to spend their energy)
      Are you going to keep the top-view sight ? It may be an adequate view for a plane or car, but not so good to represent a combat robot (on wheels, tank treads, biped, quadruped etc).

      Edgar Reynaldo

      It crashed again. The dump file is 110 MB and I can't upload that from here, and it would still take a while anywhere else. And DEP closed the program too.

      This is as far as the console got :


      And this is what the problem details said :

      Problem signature:
        Problem Event Name:	BEX
        Application Name:	PixelBots.exe
        Application Version:
        Application Timestamp:	51ee204f
        Fault Module Name:	StackHash_d34b
        Fault Module Version:
        Fault Module Timestamp:	00000000
        Exception Offset:	060d2ac0
        Exception Code:	c0000005
        Exception Data:	00000008
        OS Version:	6.0.6001.
        Locale ID:	1033
        Additional Information 1:	d34b
        Additional Information 2:	20752c25712bf3f7bc825928e900516d
        Additional Information 3:	f29a
        Additional Information 4:	c436154ffc56d491095fa90afd9656e7
      Read our privacy statement:

      And it didn't even get as far as Crash Reporter to run, so there are no logs.




      Max Savenkov
      Audric said:

      Are you going to keep the top-view sight ? It may be an adequate view for a plane or car, but not so good to represent a combat robot (on wheels, tank treads, biped, quadruped etc).

      Top-down view is the simplest one for graphics. It will definitely stay this way during prototyping, because I can create tiles & robots for it myself. For the game itself, I was thinking about JRPG-like view. Of course, the best option would be isometric view, but I simply can't create necessary art myself, and I don't have an artist who could help me for free (and I'm not going to sink money into this project until I'm pretty sure I can finish it).

      It crashed again. The dump file is 110 MB and I can't upload that from here, and it would still take a while anywhere else. And DEP closed the program too.

      So, it crashes in render initialization (as was expected, more or less). I have to ask (should have done it earlier!): do any OTHER Allegro projects that are using OpenGL run normally on your machine? I remembered a case now, with my own Netbook a while ago, which simply could not initialize OpenGL when Allegro asked for it, and crashed inside driver. Because Intel's drivers for Vista & Win7 are so bad I want to weep over them (namely, they do not seem to support OpenGL 1.2), even though XP and Linux drivers are OK.

      If this is the case, then we have a problem here... I can't give you fullscreen DirectX version, because Allegro crashes, and OpenGL version won't work too. If so, I think I will do two things: first, I would spend some time trying to isolate that crash and check if it is my mistake, or an error in Allegro. Then, if this error can't be fixed quickly, I will proceed with my current plan: to make resizeable GUI (instead of pile of hacks and hardcode which was used in this prototype) which will work under any resolution without scaling. This may take some time, however, about a week at least.

      EDIT: A-ha! It seems like I have found the culprit. Things stop crashing when I do not initialize TTF addon. I will try to recompile Allegro with a newer version of FreeType.

      EDIT2: Recompiling did not help, but the other thing did. It seems I have to call al_init_ttf_addon BEFORE creating display, but only in fullscreen modes with non-desktop resolution. This isn't mentioned anywhere in docs, I believe, and I think it's a bug, but for now moving initialization code fixed fullscreen mode in DirectX. I have to run to work right now, but I'll have another version for you to try soon.


      I've played around with a more symbolic representation, in side view. This would need the rotations to be disabled.

      Mark Oates

      maybe add a little sense of depth


      could be cool :)

      Edgar Reynaldo

      A BEX error means the program is trying to execute read only memory - something that viruses do. Trust your DLL's? Everything built with the same version of your compiler?

      Max Savenkov

      Audric, Mark Cool! That's closer to what I was thinking about for final version. I was also planning to use 3 sprites for each robot: side view which could be flipped, front view and back view. This could prove to be problematic, though, because it may be hard to tell some bots from each other in front/back view... But using only side view would look a bit wrong, even with added depth, I think.

      Edgar, I don't think there is a REAL BEX issue here. I run Windows 7 with the same protection mechanism turned on, and it does not throw a warning, and nobody else has reported such issue. Anyway, here's a scan result from VirusTotal - clear.

      I think it's really a driver issue, and that's why you are seeing BEX error. Anyway, I have prepared a new test version for you to try, which is now again uses DirectX instead of OpenGL and should therefore work even on Intel cards with bad drivers. It also handles different resolutions slightly better, or so I hope.

      Here it is: pixelbots_proto01_debug.zip

      ALL: Now that Shadowrun Returns is out my productivity is at risk of dropping further. Hey, come on, I'm just researching modern tactic combat games!

      Chris Katko

      Ah, that seems to be a problem. UI and window size is really not adaptable. 1024x768 is a minimum :( Let's see if I can hack resolution selection and scaling into that code quickly...

      FYI, if you want people to play your game, you shouldn't expect more than 1024x600 because that is a very common netbook resolution. My Asus Eee PC, for instance, causes me great distress when forms are cut off (most commonly in Linux.)

      As always, congratulations on your progress so far, and good luck!

      Max Savenkov

      Chris, yes, I'm aware of that, but I decided to cut some corners for prototype. May be too many :)

      Edgar Reynaldo

      This time your game opened the options window and I went to start a fullscreen game and it crashed. You didn't include debugging symbols so I can't debug it. And, Task Manager couldn't even kill it. I had to kill it with the parent process running it. Then I ran it in windowed screen and it worked, although I got my butt handed to me by a 200hp warrior I could only do 3 damage to.

      Max Savenkov

      Symbols are present in archive, "bin\PixelBots.pdb". If they does not work somehow, you can just post numeric addresses from stack of main thread here and I'll try to decode them with .map file.

      According to my (admittedly incomplete) statistics, of 8 games recorded 4 were won, including one on Hard difficulty, so "butt handing" part is optional :) I have to admit that battle with boss currently lacks any elegance, though, because he does not have special AI and can't even use abilities.

      Edgar Reynaldo

      When I run it through WinDbg, it immediately crashes with a BEX error again. And if I run it outside the debugger in fullscreen it crashes. I don't really know how to use WinDbg, but here is the output :

      CommandLine: C:\Games\PixelBots_pre_alpha-MaxSavenkov\bin\PixelBots.exe
      Symbol search path is: *** Invalid ***
      * Symbol loading may be unreliable without a symbol search path.           *
      * Use .symfix to have the debugger choose a symbol path.                   *
      * After setting your symbol path, use .reload to refresh symbol locations. *
      Executable search path is: 
      ModLoad: 00270000 002ee000   PixelBots.exe
      ModLoad: 77c00000 77d28000   ntdll.dll
      ModLoad: 76830000 7690c000   C:\Windows\system32\kernel32.dll
      ModLoad: 69470000 6964c000   C:\Games\PixelBots_pre_alpha-MaxSavenkov\bin\allegro_monolith-5.1.dll
      ModLoad: 76fc0000 7705d000   C:\Windows\system32\USER32.dll
      ModLoad: 76690000 766db000   C:\Windows\system32\GDI32.dll
      ModLoad: 76ef0000 76fb6000   C:\Windows\system32\ADVAPI32.dll
      ModLoad: 76920000 769e2000   C:\Windows\system32\RPCRT4.dll
      ModLoad: 770f0000 77c00000   C:\Windows\system32\SHELL32.dll
      ModLoad: 76b40000 76bea000   C:\Windows\system32\msvcrt.dll
      ModLoad: 77d80000 77dd8000   C:\Windows\system32\SHLWAPI.dll
      ModLoad: 766e0000 76824000   C:\Windows\system32\ole32.dll
      ModLoad: 77070000 770e3000   C:\Windows\system32\COMDLG32.dll
      ModLoad: 72fc0000 73045000   C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.6001.18523_none_886c608850a2f36f\COMCTL32.dll
      ModLoad: 74d90000 74dc2000   C:\Windows\system32\WINMM.dll
      ModLoad: 76d90000 76e1d000   C:\Windows\system32\OLEAUT32.dll
      ModLoad: 74d50000 74d89000   C:\Windows\system32\OLEACC.dll
      ModLoad: 763d0000 763d7000   C:\Windows\system32\PSAPI.DLL
      ModLoad: 6b190000 6b25b000   C:\Windows\system32\OPENGL32.dll
      ModLoad: 6d480000 6d4a3000   C:\Windows\system32\GLU32.dll
      ModLoad: 6a400000 6a4e5000   C:\Windows\system32\DDRAW.dll
      ModLoad: 747f0000 747f6000   C:\Windows\system32\DCIMAN32.dll
      ModLoad: 76470000 765fa000   C:\Windows\system32\SETUPAPI.dll
      ModLoad: 73050000 7305c000   C:\Windows\system32\dwmapi.dll
      ModLoad: 74ac0000 74c6b000   C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.6001.18551_none_9e7a1850c9c1b3dc\gdiplus.dll
      ModLoad: 71640000 716ff000   C:\Windows\system32\MSVCR100.dll
      ModLoad: 76d20000 76d4d000   C:\Windows\system32\WS2_32.dll
      ModLoad: 76910000 76916000   C:\Windows\system32\NSI.dll
      ModLoad: 61b80000 61b98000   C:\Games\PixelBots_pre_alpha-MaxSavenkov\bin\zlib1.dll
      ModLoad: 71410000 71479000   C:\Windows\system32\MSVCP100.dll
      (ec8.e34): Break instruction exception - code 80000003 (first chance)
      eax=00000000 ebx=00000000 ecx=0019f3ec edx=77c596f4 esi=fffffffe edi=00000000
      eip=77c47b0e esp=0019f404 ebp=0019f434 iopl=0         nv up ei pl zr na pe nc
      cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
      *** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll - 
      77c47b0e cc              int     3

      Max Savenkov

      This output does not contain callstack beyond the last address, which is DbgBreakPoint in ntdll. There are two useful commands you can try in WinDbg:

      !analyze -v

      will dump a lot of info, some of which may be useful

      And you can view callstack by simply typing


      or by using View->Callstack (there are also windows for switching current thread there).

      Edgar Reynaldo

      Didn't get much of anything useful out of WinDbg. Couldn't load symbols even when I set it with .sympath c:\blah...

      I don't know, but allegro seems to successfully set the video mode to 1280 x 800 fine, but it chokes on 1024x768 fullscreen for some reason. Used ex_display_options and things are screwed up and it gags on the window for a while and keeps spawning new windows... :P

      Max Savenkov

      Is 1024x768 present in list of supported modes at all? As to spawning of new windows, it seems to me that Allegro tries to find a workable resolution when requested one fails. That can lead to a prolonged start up and maybe even a crash.

      Edgar Reynaldo

      ex_monitorinfo says there are two 1024x768 modes supported, and my graphics driver can change the res to 1024x768 no problem.

      I tried using A5.1.7 to set 1024x768 fullscreen and while it worked with OpenGL, it took a long time and showed a subsection of my desktop for a while before it cleared the screen. Using DirectX was much faster and cleaner every time, but in the end both set the resolution successfully.

      What does your screen setup code look like? This is all the code I used to test fullscreen 1024x768.

      1 2 3#include <cstdio> 4 5 6#include <allegro5/allegro.h> 7#include <allegro5/allegro_direct3d.h> 8 9int main(int argc , char** argv) { 10 11 12 if (!al_init()) {return 1;} 13// int DRIVER = ALLEGRO_OPENGL; 14 int DRIVER = ALLEGRO_DIRECT3D; 15 16 al_set_new_display_flags(ALLEGRO_FULLSCREEN | DRIVER); 17 ALLEGRO_DISPLAY* display = al_create_display(1024,768); 18 if (!display) {return 2;} 19 20 al_clear_to_color(al_map_rgb(255,255,255)); 21 al_flip_display(); 22 23 al_rest(7.0); 24 25 return 0; 26}

      Max Savenkov

      Here's main part of Reinit function that I use to close windowed mode and go to fullscreen:

      1void AllegroRender5::Reinit( ERenderType type, bool fullscreen, int w, int h, bool vsync ) 2{ 3 al_set_new_display_option( ALLEGRO_VSYNC, vsync ? 1 : 2, ALLEGRO_SUGGEST ); 4 al_set_new_display_flags( ( m_fullScreen ? ALLEGRO_FULLSCREEN : ALLEGRO_WINDOWED ) | ( type == RENDERTYPE_DIRECT3D ? ALLEGRO_DIRECT3D : ALLEGRO_OPENGL ) ); 5 6 al_unregister_event_source( m_eventsQueue, al_get_display_event_source( m_display ) ); 7 al_destroy_display( m_display ); 8 m_display = al_create_display( w, h ); 9 if ( !m_display ) // Fallback 10 Reinit( type, false, 800, 600, true ); 11 else 12 al_register_event_source( m_eventsQueue, al_get_display_event_source( m_display ) ); 13 14 assert( m_display && "Failed to set new display mode" ); 15}

      By the way, current code does not try to set 1024x768. I modified it to try to get your desktop resolution and set it as fullscreen. Maybe this is wrong. Here's code:

          ALLEGRO_MONITOR_INFO info;
          if( al_get_monitor_info( 0, &info ) )
            render.Reinit( RENDERTYPE_DIRECT3D, true, info.x2-info.x1, info.y2-info.y1, true ); 
          else // Keep current resolution (800x600 probably)

      Edgar Reynaldo

      Well, I checked al_get_monitor_info's return information and I get 0,0 to 1280,800 on adapter 0 on my laptop, so that shouldn't be the problem.

      Do you have mingw setup? I can't debug with MSVS, but I can with gdb and g++, if you include debugging symbols.

      I can see how your code would crash if you fail to set the successful resolution though, and that is because you would be unregistering the event source from the display twice and on a destroyed display the second time through. Unless al_unregister_event_source accounts for that somehow by checking if that source is actually registered. If you call Reinit for windowed mode you will also be destroying the display twice. Don't know why it fails in the first place though.

      That's all I can see from what you've shown me, and I don't know what else would cause it.

      Max Savenkov

      Unfortunately, I don't have MinGW installed, or makefiles to use with it. I can upload a version with full debugging information, which could maybe help with WinDbg. Also, you can try to get callstack information after crash with ProcessExplorer (Process properties -> Threads -> Stack. It also can create mini and full memory dumps.

      Edgar Reynaldo

      Are you using OpenGL in that last exe you gave me? pixelbots.exe's top frame is inside atioglxx.dll. What is the development support like for OpenGL with MSVS? What versions are supported?

      Call stack for pixelbots.exe at time of crash on main thread :


      Kris Asick

      I'm absolutely terrible at strategy games (save for anything made by Bullfrog before EA bought 'em out) so I probably won't be trying out yours, but it's awesome that my own stuff served to help inspire you towards your own designs! :)

      The name seems odd though... You call them "Pixel" bots except they don't exactly look pixelated or such. The "Pixel" in "PixelShips" is referring to the fact that each ship is made up of component pixels that are simply tiny little blocks which fit together, thus when you destroy a ship, you need to pick up all of the pixels to successfully collect it. Even in the design stuff for PixelShips 2, the ships retain this pixelated look, just with higher resolution graphics, and there's even an emphasis on mixing and matching pixels to form new ships.

      Unless you're referring to the fact that the maps just look like big pixel squares, but then that just makes the title even more misleading since it's the world that's pixelated, not the bots.

      *shrugs* Ah well. It's your game you can name it whatever you want. ;)

      Max Savenkov

      Kris, it's a working title and it mostly reflects roots of game's idea, but not really related to actual gameplay. I think I will change it later.

      Edgar, that's very strange! The latest debug version should not be using OpenGL at all, only DirectX. How it ended up in atioglxx.dll is a mystery to me, unless ATI routes DirectX calls through it intentionally (which is silly). Are you sure you're using the latest version I uploaded? I have chcecked active threads with ProcessExplorer for it, and I only see nvd3dum.dll, which is NVidia's D3D driver (when I run OpenGL version, I see nv3ogl.dll).

      Edgar Reynaldo

      Mind giving me the link again, or have you uploaded it to your website again? No version numbers or dates makes it a tad confusing.

      Max Savenkov

      Here it is. Actually, yes, I should begin numbering my versions, you're right, at least with build data/time.

      Edgar Reynaldo

      No, sorry, it is still crashing in the same place when I try to set full screen.

      According to Process Explorer

      17 atioglxx.dll!DrvPresentBuffers+0xa2011

      I'm not having much luck with WinDbg either. Even when I set the symbol search path to your bin directory it says it still can't find debugging symbols. Your symbols don't work for some reason. Funny thing is when I run the program from WinDbg it crashes with a BEX error before the game's window even opens, instead of crashing when I try to run full screen.

      I don't know but maybe there is some kind of binary incompatibility somewhere. That's the only reason I can think of why this would happen, because I have no problems setting 1280x800 on my laptop with A5.

      Sorry I can't help more.

      Here's !analyze -v if it helps. Check out the last control transfer part. It tells you the last two places where the instruction pointer was.

      Edit- Nevermind, ln 77877b0e lists ntdll!DebugBreakPoint as the last symbol accessed.

      10:000> !analyze -v
      3* * 4* Exception Analysis * 5* *
      7 8***** OS symbols are WRONG. Please fix symbols to do analysis. 9
      13*** Your debugger is not using the correct symbols
      15*** In order for this command to work properly, your symbol path
      16*** must point to .pdb files that have full type information.
      18*** Certain .pdb files (such as the public OS symbols) do not
      19*** contain the required information. Contact the group that
      20*** provided you with these symbols if you need this command to
      21*** work.
      23*** Type referenced: ntdll!_PEB
      26*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Windows\system32\kernel32.dll -
      30*** Your debugger is not using the correct symbols
      32*** In order for this command to work properly, your symbol path
      33*** must point to .pdb files that have full type information.
      35*** Certain .pdb files (such as the public OS symbols) do not
      36*** contain the required information. Contact the group that
      37*** provided you with these symbols if you need this command to
      38*** work.
      40*** Type referenced: nt!IMAGE_NT_HEADERS32
      43*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Windows\system32\ole32.dll - 44 45FAULTING_IP: 46ntdll!DbgBreakPoint+0 4777877b0e cc int 3 48 49EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) 50ExceptionAddress: 77877b0e (ntdll!DbgBreakPoint) 51 ExceptionCode: 80000003 (Break instruction exception) 52 ExceptionFlags: 00000000 53NumberParameters: 3 54 Parameter[0]: 00000000 55 Parameter[1]: a20b0d78 56 Parameter[2]: 778896f4 57 58FAULTING_THREAD: 000016ac 59 60DEFAULT_BUCKET_ID: WRONG_SYMBOLS 61 62PROCESS_NAME: PixelBots.exe 63 64ADDITIONAL_DEBUG_TEXT: 65Use '!findthebuild' command to search for the target build information. 66If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols. 67 68MODULE_NAME: ntdll 69 70FAULTING_MODULE: 77830000 ntdll 71 72DEBUG_FLR_IMAGE_TIMESTAMP: 4cb733dc 73 74ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached. 75 76EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid 77 78EXCEPTION_PARAMETER1: 00000000 79 80EXCEPTION_PARAMETER2: a20b0d78 81 82EXCEPTION_PARAMETER3: 778896f4 83 84MOD_LIST: <ANALYSIS/> 85 86PRIMARY_PROBLEM_CLASS: WRONG_SYMBOLS 87 88BUGCHECK_STR: APPLICATION_FAULT_WRONG_SYMBOLS 89 90LAST_CONTROL_TRANSFER: from 778a2fe6 to 77877b0e 91 92STACK_TEXT: 93WARNING: Stack unwind information not available. Following frames may be wrong. 940029f958 778a2fe6 7ffdf000 7ffdc000 778f51b8 ntdll!DbgBreakPoint 950029fa9c 7786094d 0029fb2c 77830000 71b8cd79 ntdll!RtlTimeToElapsedTimeFields+0x446f 960029fb08 7786dfc7 0029fb2c 77830000 00000000 ntdll!RtlSetHeapInformation+0x69 970029fb18 00000000 0029fb2c 77830000 00000000 ntdll!LdrInitializeThunk+0x10 98 99 100FOLLOWUP_IP: 101ntdll!DbgBreakPoint+0 10277877b0e cc int 3 103 104SYMBOL_STACK_INDEX: 0 105 106SYMBOL_NAME: ntdll!DbgBreakPoint+0 107 108FOLLOWUP_NAME: MachineOwner 109 110IMAGE_NAME: ntdll.dll 111 112STACK_COMMAND: ~0s ; kb 113 114BUCKET_ID: WRONG_SYMBOLS 115 116FAILURE_BUCKET_ID: WRONG_SYMBOLS_80000003_ntdll.dll!DbgBreakPoint 117 118Followup: MachineOwner 119---------

      Max Savenkov

      I'm out of ideas for now. Let's wait for the second prototype. It will have resizeable GUI, so anyone will be able to play in windowed mode in any resolution and also I will try to integrate better crash reporting tool (although so far I'm finding Google BreakPad somewhat strange under Windows).

      Neil Roy

      I found 1280xwhatever to be quite nice. It is supported in various resolutions. For me, 1280x720, my wife's screen, 1280x1024. In one of my programs I took the desktop resolution, figured out the ratio then multiplied 1280 by that ratio to fit it to the screen (or just use the desktop resolution).

      On my current game it is in 800x600, which is simple to use in windowed mode and for full screen I set it to a fullscreen window the size of a desktop resolution, and then stretch everything to fit using ALLEGRO_TRANSFORM.

      Edgar Reynaldo

      Hey, Max - why don't you try 1280 x 800 (or the users desktop size) with ALLEGRO_FULLSCREEN_WINDOW? That at least lets you minimize and maximize the window easily.

      Max Savenkov

      Because current UI can't handle resolution changes. It could only scale using ALLEGRO_TRANSFORM, but scaling usually hurts fonts readability.

      I'm already working on UI that will try to fit any resolution by repositioning & stretching, and when I'm done, I will do exactly what you are proposing: use desktop's resolution or FULLSCREEN_WINDOW.

      Thread #613008. Printed from Allegro.cc