Looking for Help Arranging Tiles

[C-Dawg]

Hey all,

As Zodiac wraps up, I'm taking a class in Allegro and C++ so my next project will not be dependent on another person's engine. So far, I'm up to being able to define my own 2-d integer array and have that draw blocks on the screen that a little dude can run and jump around on. Hooray!

In between learning the API and strange little things like how to pass 2D arrays in C++, that you need a ";" at the end of struct definitions, and so forth, I'm also starting work on the tilesets and sprites. I see there are utilities like Mappy and Tiled that allow you to draw tilemaps similar to what Zelda Classic allows. They even have a rough approximation of ZC's "combo" editor, as far as I can tell, that allows you to store data with the graphics.

What they do NOT appear to be able to do is re-arrange tiles on the tilesheet. As anyone who has used Zelda Classic knows, drawing a screen without an organized combo list is a nightmare. You need to group walls and corners next to each other so the designer can FIND the damn things. I'm making my own tileset at 32x32 in Aseprite, so I can export large sprite sheets of any dimension easily. However, I'm drawing them on 64x64 canvasses so that larger walls and objects line up for me to view as a group. When I export the sprite sheet from Aseprite and then load it into Mappy, I get a mess that looks like it has its own algorithm for just loading whatever into the "tile palette" (for lack of a better word.)

I'd like to avoid having to copy and paste my way to victory by manipulating the spritesheet directly in like, MS Paint, and then using trial and error to arrange it. I'd like to be able to use a mapping utility that lets me re-organize an already loaded tile sheet, like how ZClassic lets you C and P combos.

So, that's the question. Anyone know how this is done in a utility like Tiled or Mappy? Or, failing that, is there an easier way to do this? Are there utilities that let you just cut a .png into 32x.32 squares and click to move them around?

I guess coding my own such utility would be good practice... still...

[Gleeok]

I'm with you on the state of tools for 2D tile-based games: They just all suck donkey dick. Tiled editor is pretty awesome, but the tilemaps are so generic that I can't actually see how you can use it for a full game. I don't think they even support animated tiles still! Forget about anything more complicated than that I guess. It's a damn shame.

Since I also believe that treating an image as a tileset is "doing it wrong", I ended up just making my own. It easily supports anything ZC can do, and it let me extract all the maps from the PSP ROM and put them in my own format. The down-side is that I can't use an existing map editor tool, and have to write my own, which I haven't quite done yet... I guess you just have to pick your poison. I can tell you that 2D tilemap stuff is stupid easy, but perhaps only if you've written them before--my first iteration was a little crappy to be honest. As with anything in c/c++ it's easy to write bad code and hard to write good code.

As far as utilities for images go, I don't know. I haven't really seen any, but then again I am not particularly good or experienced at pixel-graphics stuff, only the code that uses it. I do know that graphics gale free lets you move rectangles around pretty easily though. I once used it for bitmap fonts.

Are you trying to port Zodiac, or working on something new?

[C-Dawg]

Porting Zodiac would be an very interesting challenge, since I'd have to recreate the source code of ZClassic from the ground up! Maybe worth it some day, after all, ZClassic crashed the reviewer's computer during the Twitch review of Zodiac last night, much to everyone's amusement. He did, however, soldier through and really enjoyed the game while praising the current devs, including you.

No, at the moment my intention was to start a newer project. Another metroidvania, but with a few new twists mechanically. So far, I'm able to get a little one-screen platformer working, but as I start to delve into object-oriented design for an engine, I need a reliable way to make lots of maps. I might later work with someone else on the map-making side of things, so a good mapmaking tool is a must.

I'd be interested to see what you came up with. Did you use Allegro 5? If there's nothing good out there, perhaps I can look at that and make my own utility application. What I'd be looking for is something that acts kinda like ZClassic does... just thinking out loud here...

1. Create "combos" by selecting a 32x32 pixel portion of a PNG at a time, building a combo palette like ZQuest has so tilesets are well organized;
2. Each "combo" having an array attached of, say, 50 ints that can be loaded with whatever. Used for flags and types on the combo, but not defined in the map maker. Also probably have a string for each combo so you can name similar combos with different properties.
3. Ability to point and click single combos at a time, define "brushes" like Mappy does, and possibly do relational drawing of large edges (though that would take some serious setup).
4. Output a three-dimensional array; [x][y], with each element just being an integer index to the combo sheet. Also output a "combo sheet" that is attached to the map and defines the properties of each tile.
5. Simple functions to load/draw a map saved in the format we created and return one of the elements 3rd dimension array.

I envision then just defining constants in the game engine like SOLIDITY = 1; FRICTION = 2; and that kind of thing that would allow you to quickly access "properties" of the tile. Like, current_map.get_property(x,y,FRICTION); or something.

That makes the mapping utility as minimal as possible and gives lots of flexibility to how you would use it.

Continuing to think out loud here, let me think about the next things I need to know to make this utility: 1. Multiple windows or at least the appearance of them; 2. Capturing mouse input other than the "x" to close the window; 3. file i/o for graphics and 3d arrays; 4. importing outside resources into Visual C++ (I know they have tons of folders set up for this purpose); and... I think thats it. I really have no idea how to create output that I can then use in Visual C++, but I'll learn.

I'll start tinkering with some of the basic things I need to learn this weekend. You wanna help out with this, Gleeok?

EDIT: This guy states the problem better than me:
http://forum.mapeditor.org/t/tiled-needs-to-be-optimized-for-work-with-tilesets-under-active-development/678

EDIT2: In fact, now that I look more at Tiled, it looks like that utility may have MOST of the functionality I'm looking for. Looks like you can't move your "combos" around after you've made a map, but otherwise it looks pretty solid...

[Anarchy_Balsac]

If it's simple enough, you can use a character matrix that reads from a text file to create your levels, then making your maps is as simple as editing the text file.

But a better way for Metroidvania games is to use XML with an integer matrix. I don't remember exactly how it worked, but I've used it before and it's effective.

Now, for either of these two methods, you will have to view your level, when editing it, in a way such as this:

.................................................. .........................
............G..................................... .........................
.......--------....................---------...............................
.................................................. .........................
........................e......................... .........................
....................--------....................---------..................
.................................................. .........................
.......................................e.......... .........................
.......----------................---------.................................
.................................................. .........................
.....P............................................ .........................
tttttttttttttttttttttttttttttttttttttttttttttttttt tttttttttt

or this:
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.000.000.177.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.003.003.003.003.000.000.000.000.000.000.00 0.003.003.003.003.000.000.
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.000.000.000.000.000.003.003.003.003.000.00 0.000.000.000.000.000.000.
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.000.000.091.000.000.000.000.000.000.000.00 0.091.000.000.000.000.000.
000.000.000.003.003.003.003.000.000.000.000.000.00 3.003.003.003.000.000.000.
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.020.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
100.100.100.100.100.100.100.100.100.100.100.100.10 0.100.100.100.100.100.100.

But it works, it allows you to have a sense of scale, AND it is nowhere near as cumbersome as developing a whole level editor.

[C-Dawg]

If it's simple enough, you can use a character matrix that reads from a text file to create your levels, then making your maps is as simple as editing the text file.

But a better way for Metroidvania games is to use XML with an integer matrix. I don't remember exactly how it worked, but I've used it before and it's effective.

Now, for either of these two methods, you will have to view your level, when editing it, in a way such as this:

.................................................. .........................
............G..................................... .........................
.......--------....................---------...............................
.................................................. .........................
........................e......................... .........................
....................--------....................---------..................
.................................................. .........................
.......................................e.......... .........................
.......----------................---------.................................
.................................................. .........................
.....P............................................ .........................
tttttttttttttttttttttttttttttttttttttttttttttttttt tttttttttt

or this:
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.000.000.177.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.003.003.003.003.000.000.000.000.000.000.00 0.003.003.003.003.000.000.
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.000.000.000.000.000.003.003.003.003.000.00 0.000.000.000.000.000.000.
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.000.000.091.000.000.000.000.000.000.000.00 0.091.000.000.000.000.000.
000.000.000.003.003.003.003.000.000.000.000.000.00 3.003.003.003.000.000.000.
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.020.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
100.100.100.100.100.100.100.100.100.100.100.100.10 0.100.100.100.100.100.100.

But it works, it allows you to have a sense of scale, AND it is nowhere near as cumbersome as developing a whole level editor.

Yeah, Im aware of that method. That's how I've got my one-room game thing working at the moment; I just raw-dogged an integer array and told my code what to do with it. An editor would ideally output something very similar to that, plus the .pngs themselves.

The problem is:

(1) I'm making my own tileset, and I'm aiming for SNES-quality with slightly higher resolution. This means LOTS of tiles. I am not barfing out some stupid-looking JPRG field tiles here, I'm taking my prior work up a notch by making something that looks more like Super Metroid-quality. (For those who are interested, I'm trying to do an artistic theme similar to Ultionus: A Tale of Petty Revenge; big, colorful, and very "poppy" if that makes sense.) This means LOTS of tiles, and potentially lots of different tile properties. Using integer arrays will be very, very hard to keep straight.

(2) I don't plan on doing all of the mapping myself because, let's face it, it took me 7 years to finish Zodiac. Even without a 5 year hiatus in the middle, this time I gotta make an ENGINE first, and lord knows how long that'll take. The easiest thing to get outside help with is map making, since anyone can do that (though few can do it WELL and consistently) without knowledge of programming.

So, I gotta have some fairly robust map making software that I can load into whatever Allegro engine I end up excreting.

[Anarchy_Balsac]

I know what you mean, it's a tad cumbersome, but it works, and you can get used to it faster than you might think. The time you'll spend making an editor will be exorbitantly long and probably not worth it. I know this from experience because I tried it myself, and adapting to the above method really was the better option. It's annoying until you get used to it, but you WILL get used to it, and far more practical than it might seem at the moment.

An editor is only worth it if you need people to build your maps for you.

BTW - is this an actual Metroid game?

[C-Dawg]

I know what you mean, it's a tad cumbersome, but it works, and you can get used to it faster than you might think. The time you'll spend making an editor will be exorbitantly long and probably not worth it. I know this from experience because I tried it myself, and adapting to the above method really was the better option. It's annoying until you get used to it, but you WILL get used to it, and far more practical than it might seem at the moment.

An editor is only worth it if you need people to build your maps for you.

BTW - is this an actual Metroid game?

An "actual Metroid game?" Heavens no. I don't have the intellectual property rights for something like that. I may like to pay homage to older games, but I want to develop my own characters and story rather than cribbing off and existing franchise.

Of course, this is very early; details will be evolving as I work on this.

[Gleeok]

Oh god... don't use byte-maps! :P

The problem is going back and forth to see if it "looks right" ad infinitum... Plus, wait 'till you add in event layers, objects, enemies, dialogs, etc.. and try and manage all that with text files.
Works great for just throwing together a quick map for gameplay prototyping though.



I'd be interested to see what you came up with. Did you use Allegro 5? If there's nothing good out there, perhaps I can look at that and make my own utility application. What I'd be looking for is something that acts kinda like ZClassic does... just thinking out loud here...

1. Create "combos" by selecting a 32x32 pixel portion of a PNG at a time, building a combo palette like ZQuest has so tilesets are well organized;
2. Each "combo" having an array attached of, say, 50 ints that can be loaded with whatever. Used for flags and types on the combo, but not defined in the map maker. Also probably have a string for each combo so you can name similar combos with different properties.
3. Ability to point and click single combos at a time, define "brushes" like Mappy does, and possibly do relational drawing of large edges (though that would take some serious setup).
4. Output a three-dimensional array; [x][y], with each element just being an integer index to the combo sheet. Also output a "combo sheet" that is attached to the map and defines the properties of each tile.
5. Simple functions to load/draw a map saved in the format we created and return one of the elements 3rd dimension array.

I envision then just defining constants in the game engine like SOLIDITY = 1; FRICTION = 2; and that kind of thing that would allow you to quickly access "properties" of the tile. Like, current_map.get_property(x,y,FRICTION); or something.

That makes the mapping utility as minimal as possible and gives lots of flexibility to how you would use it.

Continuing to think out loud here, let me think about the next things I need to know to make this utility: 1. Multiple windows or at least the appearance of them; 2. Capturing mouse input other than the "x" to close the window; 3. file i/o for graphics and 3d arrays; 4. importing outside resources into Visual C++ (I know they have tons of folders set up for this purpose); and... I think thats it. I really have no idea how to create output that I can then use in Visual C++, but I'll learn.

I'll start tinkering with some of the basic things I need to learn this weekend. You wanna help out with this, Gleeok?


I didn't use allegro 5. I'm not a fan of allegro 5 for three reasons: It's bulky, there's too many add-ons that have too many dependencies, and the event handling is difficult. I use my own windows layer that can use either Win32, SFML, GLFW, or whatever to make a window, handle input and gamepads, etc. Took a bit of work, but I am not dependent on any libraries or chain of library dependencies. :) Why get all the extra bloat when you can do it yourself?

For what it's worth; I spent so much time on the engine that I fell way behind in other things, like, you know, the actual game stuff. It's a pretty deadly trap, actually. I kept thinking "oh no problem, I can just add this, then that, then refactor this... then that." It's all fine if you can spare 8 hours a day on a game like a "professional" indie dev, but as a spare time thing it sucks up most of your time very quickly, possibly years, especially so if you are still learning the basics. There's nothing like spending a few days on some little stupid thing only to realize you haven't actually anything important to the game! :P You might want to get someone dedicated to music, and another for low-lever engine code, maybe, so you can just work on the game itself and learn it by doing that.

Funny enough, it just happens that the next thing on my todo list is map event and object layers. Well actually there's about a dozen other things associated with that, but yeah, all that good stuff. I kind of miss the simple shmups, those were so much easier to make.

Sure, I'll help you out. You can also look at anything else I've done, feel free to ask away.

[Anarchy_Balsac]

Oh god... don't use byte-maps! :P

The problem is going back and forth to see if it "looks right" ad infinitum... Plus, wait 'till you add in event layers, objects, enemies, dialogs, etc.. and try and manage all that with text files.
Works great for just throwing together a quick map for gameplay prototyping though.

Oh I know, I've done it. Maybe I just have a much easier time with it than yall do.

[C-Dawg]

Gleeok, I will probably take you up on that offer to some extent. I didn't reach out to you as a programmer initially because I know you have your own fish you're busy frying.

As for Allegro 5, I figure that bloated code can't be THAT bad when we're just talking about a 2-d, tile-based platformer. I mean, I was able to do everything I wanted in Zodiac using just 32 FFC objects, why can't I get similar results using Allegro 5? Besides, my goal here is to get an engine that's JUST good enough to do what I need without getting to crazy. From there, I can work with what I have, like did with ZQuest. I don't need tons of features, I just need a bare-bones engine and I can tinker from there.

I chose Allegro 5 basically because it's user-friendly. I mean, I was from hello-world to making sprites move around in a total of like 4 hours, and most of that was spent looking up the API. My strategy is to make a series of smaller games (based loosely on the on-line curriculum I'm working on) and slowly grow to understand what's possible and what's not. Along the way, I'm making assets as I need them for what I'm doing and stashing them away for later use in design.

By way of example, I now have a little game (just main.cpp) that has one screen with blocks defined by a byte-map. You walk and jump this little astronaut around, he can shoot projectiles and blow up infinitely spawning green hoppy things. Right now all the sprites are just structs that store the relevant variables, and the game loop just adds and removes them to vectors (EnemyList, PBulletList, EffectList, etc) as needed, and handles stuff like applying Vx and Vy. I need to implement a few more things like sound and a score board, but I think I know how to use fonts and sound already.

From there, I want to figure out:
1) Non-keyboard input, at least from X-box
2) Mapping utilities (like I said earlier, but at first blush Tiled looks like it does what I want)
3) True object-oriented design
4) File i/o
5) Manipulating the size of the window, full screen mode, and size of sprites and tiles.
...and probably 50 more things I'm not even thinking of that I'll run into.

I'm sure I'll run into more issues as I dig deeper. Like, I'm told that to make Tiled output (.xml) work with Allegro, I need to code a "parser." I have no idea what that is, except in the broad sense that I guess it reads the .xml file, but i'll get there eventually. I don't know how to use all the sub-folders that Visual C++ provides.

All that said, if you want to help out, that's cool. I'm not really ready to collaborate right now, though, because I don't really know what I'm doing yet. If you want to dropbox me your map editor utility, that will probably help me understand file i/o and some other basic concepts I'm not thinking about. Any other "lessons" you want to toss my way would be appreciated. And, who knows? Maybe down the road you can help with streamlining whatever horrible, noodly mess of code I come up with when I'm actually getting the real engine together.

[C-Dawg]

So, Tiled exports in an XML format. I'm having trouble understanding how to implement a parser for that kind of format. Or to incorporate someone else's. I'm using Visual C++ 2010 with Allegro 5; anyone have a class or tutorial they can point me at?

[Gleeok]

A "parser" is basically just code that turns text into something that can be logically interpreted by some other code, which then can be transformed into data. A very simple example of parsing text would be doing something with command line arguments.

I have xml, compression, and other file io built in to what I am using at the moment, so reading xml is trivial--I actually use xml for various things, basically anything I may need to open up and hand edit, and everything else is usually binary. For the actual xml parser I am using rapidxml, Every other xml library (that I know about) is just pure crap. I'd recommend using that.

I don't know if anyone has written a specific allegro5-tiled reader... I suspect not, since you'd need to know the game code to do anything useful with it.

[C-Dawg]

A "parser" is basically just code that turns text into something that can be logically interpreted by some other code, which then can be transformed into data. A very simple example of parsing text would be doing something with command line arguments.

I have xml, compression, and other file io built in to what I am using at the moment, so reading xml is trivial--I actually use xml for various things, basically anything I may need to open up and hand edit, and everything else is usually binary. For the actual xml parser I am using rapidxml, Every other xml library (that I know about) is just pure crap. I'd recommend using that.

I don't know if anyone has written a specific allegro5-tiled reader... I suspect not, since you'd need to know the game code to do anything useful with it.

Yeah, there is one, called allegro_tiled.
https://github.com/dradtke/allegro_tiled

I have what appears to be a "CMake" package but I have no idea what I'm doing with it. I got CMake, which I generally understand to be a utility that can create a Visual Studio project file out of the package. When I try to use it, I get errors.

Are you around on a chat utility like PureZC, Skype, or something later tonight?? I get the impression you could walk me through some of this. As I get beyond just writing all code in main.cpp, I find myself massively out of my element. I can't even find good tutorials or lessons to explain this kind of thing.

[C-Dawg]

Aw, fugeddabadit. At least I can get Mappy working just fine. Takes one header file, one .c file, and two lines of code and BLAMMO.

So I just have to make sure I set up very precise "templates" for map designers to use with Mappy and then I'm good to go. Cumbersome, but it does work.

[Gleeok]

Looks like allegro5-tiled has extra dependencies. Fun stuff huh? :P

I didn't know mappy was still being worked on. Glad you got it working.

What time zone are you at? My schedule has been all whacked out the last few weeks, but getting back to normal after the weekend.

[C-Dawg]

Yeah, in theory the only tools I need to learn now are controller input, drawing the screen at different levels of zoom, and the best way to design object oriented game elements. Then I should be good to cobble together an engine and the rest of the tileset, I think.

I'm in the Mountain time zone, and usually only have a few hours around 9pm to work each day.

[C-Dawg]

Okay, so I got Xbox 360 controller support working, and I figured out how to draw the whole screen at scaled size. (Just make a temporary buffer bitmap and draw it to the backbuffer with a scale.) I've gotta do some logic to make sure the player stays centered on the screen as it zooms in and out, but I'll noodle that out later. So, with that, I mean... I think I know everything I need to know to make a game, actually. Sound, fonts, graphics, input, zoom... am I missing something I should be learning before I get into this bad boy? Going from "don't know anything about Allegro" to having a little scrolling platformer within two weeks is not the pace I expected to be working at, so I wonder if I'm missing something.

Tomorrow, I'll start doing the classes on object-oriented design and do a few more examples and then I'll start building the actual engine.

[Gleeok]

Cool. Glad you are getting everything up quickly! It's not all sunshine and beers. :P

TBH I'm kind of sad that I never got a full game of something unique out there. I had prototyped a few crazy ideas years back, one for the XBox indie thing, but I wasn't happy enough with them to scratch and redesign. Oh well. But good luck to you. You are not short of ideas I'm sure.

Quick tip: Never make a 'temp' render target every frame. Make it once, and reuse it. You can also simply set an orthographic projection matrix to match your desired pixel resolution, that's another simple way of doing it, but it sounds like you are happy with the other way. For a 'camera' you will need to use matrices though; no way around it. I've never used allegro5 but it's likely something like this:



struct Camera {
union { v2 xy; struct{ float x, y; }; };
float zoom;
};

al_transform t;
al_transform_identity(&t); //get identity which is an array or 16 floats of : 1,0,0,0,0,1,0,0,0,0,1,0,0,0,0,1
al_translate_transform(&t, camera.x, camera y);
al_scale_transform(&t, camera.zoom);
al_set_transform(&t);

// ...once per frame probably

[C-Dawg]

I don't follow your terminology; I'm a beginner, remember.

So, one of the effects I want in this game is that the "camera" zooms in closer when you hop out of your tank. Think Blaster Master, except with a more severe difference between being in and out of the tank. Very different mechanics and different map experiences at different scales.

Anyway, I don't render each frame. I don't think. What I do is, when the ev gets a TIMER event, among other things, it sets the redraw variable. Then, we go to the redrawing section. All of the drawing gets done to a ALLEGRO_BITMAP that's the same size as the display; I call it "mock_display." Mappy functions draw the map, then main.cpp draws the sprites on top of that. Finally, when everything is drawn, and before I flip(), I draw mock_display to the backbuffer using the a_draw_bitmap_scaled() command (or whatever it is exactly), doing some math to make sure the screen is zooming around the center.

What's the problem with that way of doing things? What's an "orthographic projection matrix?"

[Gleeok]

Oh, sorry. When you say "camera", "zoom", and "scaling" I think matrices and telling the GPU what you want it to do. I don't mean to be confusing, honest! :P

I think I can explain the differences a little: From your perspective you use the allegro5 API and just need it to provide functions that you can work with. From my perspective I know that allegro5 is simply a thin layer that wraps platform stuff, sound, and graphics card rendering, so when I think of a problem I don't think how allegro5 API exposes everything, I think of what allegro5 has to do under the hood to make it work. There is a huge difference between software and hardware rendering--they are completely different things--and so to create zooming or multiple resolutions it's going to use something allegro5 decided to call a 'transform'. All this is is a matrix that is sent to the GPU underneath it all. It's a little strange to me that allegro still refers to "bitmaps" though... Bitmaps don't actually exist in modern graphics. Weird. I might have to look at the docs if you ask me anytthing more about them.


https://www.allegro.cc/manual/5/transformations.html

Instead of transforms, I don't know how else to do it efficiently so you may have to ask on the forums.

[C-Dawg]

I have now successfully made the first change to object-oriented design; my little soldier dude is now running, jumping and shooting (animation alone, no bullets yet) as a class Soldier which inherits some stuff from class GameObject. X-box controller support still works (that didnt change much since I'm just calling the Soldier object from main.cpp with function calls when a button is pushed) but getting the camera and zoom features to work again was a HUGE PAIN. I had to completely reconsider the problem since now my collision detection (happening inside an object) could not directly modify the xOff and yOff from main.cpp. Got a new solution based on checking how far off center the player is and correcting it, if possible.

Next steps: figure out how to make the "camera" that handles zooming and moving around the tilemap into an object to get that code out of main, and making some enemy/projectile classes. And figure out how to coordinate multiple maps. Objects for sub-screens and menus seems pretty trivial. Huzzah! Barring some major teardown once I really master what I need to (I hope note) I could theoretically be working on the actual, honest-to-goodness engine now...

You know, I've noticed as I go along here that there's not really a good "here's everything you need" kind of tutorial for this kind of thing. Like, "what dimensions do you have to export from Aseprite to avoid having Mappy cock up the tilesheet," or "here's all the headers and C files to get Mappy and the Controller running" or even "here's how you can move the camera around a tilemap based on player input and zoom in and out." Maybe I should find a place for a little blog as I learn more?