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:

Video:

http://www.youtube.com/embed/kd38eRnYKKc

Screenshots:

Title screen and some options:
{"name":"screen_p1_01.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/d\/bd145d6e9a69dbc00710af82aecfa8c0.png","w":1040,"h":805,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/d\/bd145d6e9a69dbc00710af82aecfa8c0"}

Your bots at the start of level:
{"name":"screen_p1_02.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/6\/56a4439a9b8a5dbab4272b663378dae7.png","w":1040,"h":805,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/6\/56a4439a9b8a5dbab4272b663378dae7"}

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.
{"name":"screen_p1_03.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/0\/f00948da97273f0e64e1e128a5f30625.png","w":1040,"h":805,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/0\/f00948da97273f0e64e1e128a5f30625"}

Now this feller is about to get a load of laser blasts in his ugly bot face!
{"name":"screen_p1_04.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/b\/9b30d816a7175d3bb1a7b0cea0aa9320.png","w":1040,"h":805,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/b\/9b30d816a7175d3bb1a7b0cea0aa9320"}

Somewhat worse for the wear, but still alive. One of the bots have a Forcefiedl on.
{"name":"screen_p1_05.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/2\/32b107cb8942d3dc39489c4ae72c8b4b.png","w":1040,"h":805,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/2\/32b107cb8942d3dc39489c4ae72c8b4b"}

Green bot is the boss. He is not very hard, because he don't have special AI yet and can't use abilities.
{"name":"screen_p1_06.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/d\/4dbfd7f7936daac430dd4b791736d17f.png","w":1040,"h":805,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/d\/4dbfd7f7936daac430dd4b791736d17f"}

"Trooper" bot is about to use "Grenade" ability.
{"name":"screen_p1_07.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/e\/8ef5ef321b064a8cc9ff50418d9d95d1.png","w":1040,"h":805,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/e\/8ef5ef321b064a8cc9ff50418d9d95d1"}

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.

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.

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...

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

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,
         ALLEGRO_PIXEL_FORMAT_ABGR_8888_LE, ALLEGRO_LOCK_WRITEONLY);

      /* 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.

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.

[quote]
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.
[/quote]

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.

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?

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.

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

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.

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.

EngineLog.html

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

crashdump.dmp
crashrpt.xml

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).

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.

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)

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.

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)?

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

crashdump.dmp
crashrpt.xml

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.

Ok, thanks for the info.

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:

pixelbots_proto01_debug.zip

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).

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 :

Start
system.Init()

And this is what the problem details said :

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

Read our privacy statement:
  http://go.microsoft.com/fwlink/?linkid=50163&clcid=0x0409
 

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

Edit-

http://answers.microsoft.com/en-us/windows/forum/windows_other-windows_programs/problem-event-name-bex-error-message/cf5baf73-0877-4070-abfb-a2c3a17a9e10

http://technet.microsoft.com/en-us/library/cc738483%28WS.10%29.aspx

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).

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.

maybe add a little sense of depth

could be cool

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?

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!

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!

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

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.

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.

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 - 
ntdll!DbgBreakPoint:
77c47b0e cc              int     3

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

k

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

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...

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.

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.

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

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)
      render.ToggleFullscreen();

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.

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.

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 :

ntkrnlpa.exe!KeWaitForMultipleObjects+0xab7
ntkrnlpa.exe!KeWaitForSingleObject+0x492
ntkrnlpa.exe!PsGetCurrentThreadTeb+0x377
ntkrnlpa.exe!KeInsertQueueDpc+0x670
ntkrnlpa.exe!KeWaitForSingleObject+0x492
ntkrnlpa.exe!KeAreApcsDisabled+0x5b5
ntkrnlpa.exe!RtlGenerate8dot3Name+0x777
ntkrnlpa.exe!RtlGenerate8dot3Name+0x1944
ntkrnlpa.exe!RtlGenerate8dot3Name+0x107c
ntkrnlpa.exe!ZwQueryLicenseValue+0xbc6
ntkrnlpa.exe!ZwAlpcSendWaitReceivePort+0x11
ntkrnlpa.exe!PsAssignImpersonationToken+0x376
ntkrnlpa.exe!ExfReleasePushLockShared+0xd10
ntkrnlpa.exe!IoGetRequestorProcessId+0x2a0
ntkrnlpa.exe!KiCoprocessorError+0x173
ntkrnlpa.exe!ZwQueryLicenseValue+0xbc6
ntdll.dll!KiFastSystemCallRet
atioglxx.dll!DrvPresentBuffers+0xa2011

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.

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).

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.

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

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.

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).

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.

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.

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.