If you want to know whether a line or function has been executed, set a breakpoint for it in gdb.

gdb>break [filename]:[line_number]

Use the continue command to keep going and 'delete #' where # is the breakpoint number to get rid of a breakpoint. Use 'info breakpoints' to find the breakpoint number if you forget. If you're not already, use 'backtrace' to find the contents of the stack at the time of the crash.

Yeah, the need is for code right now. I have a short list of what music we need but I'd like to get something remotely playable first so people know what they're making music for, and just in case the list changes. I was actually going to make a new thread just to ask how much anyone knows about what we've done so far; from the look of the Programming Support Group thread maybe some people don't realize what's going on here.

Just so I'm up to speed, the coding team is basically Trezker, Matt Smith, and OnlineCop right now? I get the impression that there's some internal communication between you three in the last few days I don't know about. Is there some progress being made, if only to help OnlineCop get compiled? Has anyone else contacted you offering their help?

I need to spend some time today getting SVN and Allegro 5.0 set up, although I'm still just doing design work and finishing the necessary tilemap editor over here. Mark Oates, done any more graphics?

Me and Matt are talking on IRC. OnlineCop is pretty much on his own, he only posts in this thread and leaves some clues by committing to svn...

Then there's Mokkan who said he's gonna convert his resource manager to allegro 5, that's not a critical task though.

I have made a somewhat usable entity system with Lua interface, so you can make items and characters in script.

Matt Smith is working on menus and gui, which will be bound to Lua too.

OnlineCop is working on map code. Don't know how far along that is, unfortunate that this task fell on someone so short on time. This part is the one most people seem to be waiting for. It also seems he's working on Windows, which has that annoying Lua bug...

I already looked into that a while ago. We're not there yet.

What I've got on SVN is basically all I've got.

I don't have an IRC client, which is why I've not been chatting with anyone. So at least on my part, no, there's been no outside communication with the team except through this forum.

I've posted my backtrace report a few times now, but I can't make heads or tails out of it. With the code I've posted in branches/onlinecop, I doubt that there's a way that a NULL-pointer access is happening, since I've got all sorts of "if (blah && blah->foo != bar)"-style guards. So I'm really stumped.

I'm working with LUA 5.1.3, if that helps at all. Don't know if this is the source of the crash, but I'll have to keep digging.

And yea, I don't have as much time now as I did when the thread first started (I had a week until I started classes, so wanted to have a "one-week competition" before my time ran out ). But I'll help out whenever and with whatever I can.

Should I post what I've currently got into the main trunk, or should I leave stuff where it is (branches/onlinecop) so you can check it out and see what's there without it breaking anything?

For me at least, I have to mkdir obj in branches/onlinecop. Then I get a bunch of invalid conversion errors in src/Main_menu.cpp between line 26 and 29. So onlinecop, if you're managing to compile your branch then I'm going to say that your branch in the repository is not a full reflection of your working copy (or I'm overlooking something...).

Well for Lua I'm guessing 5.1.x should work but the latest version is 5.1.4 so that's probably the best...

I'll take a closer look on the map code. Maybe put it in trunk if it works here.

[edit] Well I would unless someone already broke the trunk...

[edit2] Trunk reverted to where it works. I also merged my own latest changes.

OnlineCop: what's with all the namechanging and making everything pointers? And why are you using std::nothrow everywhere?

Your branch is a mess, I'm guessing you manually moved files to trunk and committed. If you had a real branch you could just do the following in trunk.

svn merge -r LAST_MERGE:HEAD http://svn.miquelfire.com/monday/branches/onlinecop
Make sure everything works here, resolve conflicts..
svn commit -m "merge"

I'll be taking a look at your code now, see if it works with the trunk code.

First of all I had lots of trouble compiling it. All sorts of strange errors. You also have optimized and inlined stuff, why do that before even rendering a simple tilemap?

I also wonder what the idea is with the TILE_TYPE template? I don't see any use for a template in this. Why not just graphical layers and a special collision map?

Ok, since I was not so satisfied with onlinecops design I tore everything up and made my own... In my own branch of course. Still nothing visible, the loading code isn't in there yet.

Check out my branch if you want to have a look at my Map, Layer and Tileset classes.
http://svn.miquelfire.com/monday/branches/trezker/

I would participate, but anything I code belongs to my company However, I am still watching this from time to time (especially because I want to learn the new API).

Meh, I don't have much to do. I threw together some code because I felt like it in just a few hours.

When did we decide this whole thing had to be made from scratch BTW? I think if someone has good ready code that we could just plug in, that'd be great. If it's not a perfect fit we could just tweak it a bit. We would have had map in the engine weeks ago...

Mokkan's resource manager is an old thing he based on X-G's even older thing... I don't have it yet though...

I feel a bit bad about coding a new map system when OnlineCop had written so much code. But it was too much enterprise...

Also, I don't think the project can wait for the map much longer, I can't wait for it much longer. There's only so much I can do on entities...

I think I'm only gonna do the basics of the map. Someone else can extend the tileset class with animation, code the collision handling, line of fire, parallax scrolling...

That is unless someone throws a good map system that's done most of that. Then I can drop my code.

Well, if I'm doing it I'm continuing my own work, I kinda like how it turned out. But if someone else really likes to do tilemap coding and wants to do it another way...

While you all are thinking about that, I've completed basic loading and rendering of map.

Map file format, pretty simple. First a line saying "layer" followed by which tileset to use, then dimensions of the layer (in tiles), the the tiles in logical order. It's loaded with std::ifstream>>(int).

The tileset file just points to an image followed by the dimensions of a tile.

media/tileset_placeholder.png
32 32

So, if this works like I think it does, you can have layers with different tilesizes, the tileset determines that.

Then we could make a collision layer with it's own tilesize too, if anyone would be so crazy as to think that's a good idea. But it's almost simpler for me to implement collision of dynamic granularity than fixed so why not do that?