I took a break and worked on other projects. When I came back, I added some debug code to draw the obstructions on the tiles themselves. When I did, I accidentally changed the order to be correct.

I did something similar and found out much the same way! Haha.

If I had ever finished the web version of map parsing, I probably would've come across the same problem; thanks for confirming the correct behavior!

The funny thing about this is I got it right the first time--I don't even recall finding the RTS doc to be ambiguous about it.  I guess it just seemed natural to me that the order would go header-obstructions-header-obstructions (especially since the header includes a "has obstructions" flag) that the uncollated order never occurred to me.

The funny thing about this is I got it right the first time--I don't even recall finding the RTS doc to be ambiguous about it.  I guess it just seemed natural to me that the order would go header-obstructions-header-obstructions (especially since the header includes a "has obstructions" flag) that the uncollated order never occurred to me.

Well, other files code aren't like that, such as spritesets or windowstyles, but tiles are different. That said I found out about this very early on, after looking at some weird values returning back. I guess I didn't use maps quite like FJ's.

I guess I didn't use maps quite like FJ's.

This. Maps other than the ones I test with would have made this easy to see.

I've been using some features I've added but not extensively tested, particularly the Turbo Runtime font system. I've begun to examine how I could implement a streaming Surface system.

Right now I am attempting to simply add a blit method to Surfaces that has as little overhead as possible. The default would simply be to upload the surface every single time it will be drawn, or every time the surface is modified.
However, OpenGL has some extensions and some newer core features to make this more efficient. Some of them are Mapped Buffers and Pixel Buffers. I'm going to test out the performance and complexity of these solutions.

Ideally, I don't want to have a Surface.blit() method. I want to make a simple way to bind a Surface to an Image such that changes to the Surface are reflected in the Image automatically. I don't exactly know what I want this to look like just yet, although simply having a function or new constructor for an Image that creates an Image with a bound Surface is certainly an appealing option right now.

If this performs well enough, I may change the Turbo Runtime map engine to use this solution for layers. It would certainly make animations a bit simpler.

I don't know how closely you looked at the minisphere source, but in minisphere surfaces and images are the same object internally.  In fact, if I didn't have to stay compatible with Sphere 1.x  I wouldn't even have both--everything would be an image.  Seems like it would be much cleaner (and perhaps easier to optimize) without the distinction.

TurboSphere used to be that way, too.

Using hardware acceleration for everything, it makes sense to have both software representations of an image and a hardware representation. They have vastly different performance characteristics.

It is extremely taxing to update an image every single frame. I want to use this to limit the overall number of different Images, primarily due to GC concerns. In the case of just a simple Image, it makes no sense to keep the the software representation. If you are going to modify an image many times before use, it makes sense to keep it all in software and only touch the hardware when you actually need to draw it.

I could put that last part in the engine proper, for instance only upload the Surface once it needs to be blit, but that difference already exists in the Sphere API. That separation is the difference between Surface and Image, which is even stronger in TurboSphere since you simply cannot blit a Surface. The new idea I have would more over be a more optimized way to update an existing Image. It would still be better to just use Images and Surface wherever possible, but in a very few cases I am seeing if it would be more efficient to do it this way.

An alternative is to do what SDL does, and what I suspect Allegro mostly does, which is to draw everything on a single texture and just upload that one texture every frame. But I do not want to do that, since I want to take advantage of the GPU's geometry calculations. Even on simple stuff that equates to a memcpy(), I found an entire order of magnitude improvement when I started doing this in TurboSphere.

Another solution to the problem I am tackling right now would be to add an 'update' method to Image. But if I know that the Image will be updated often, I want to see if using PBO's or mapped buffers would be a better solution.

As far as I know all hardware bitmaps in Allegro are implemented as FBOs, which means drawing to a surface in minisphere is theoretically just as fast as drawing to the backbuffer.  As such it didn't really make sense to have separate types internally--there's no performance hit, and it helps keep the size of the engine down.  KISS.

No offense, but at times at times I feel like the TurboSphere project suffers from a very bad case of overengineering.  Maybe it's just that I enjoy refactoring, but I'd rather implement something basic that works first, and if it proves to be inadequate down the road I can always change it.  That's what source control is for!

That doesn't really make sense to me. An FBO is used to take the result of a drawing operation and put it into a texture rather than to a context. Do you mean PBO?

Even using buffer objects, it is slow to rebind them and all cards have a very limited number in comparison to the number of possible textures.

If you want to reach out and touch hardware, the separation of Image and Surface makes sense. It's true that it could all be wrapped up in the engine, but I believe that developers are quite capable of understanding and using Surfaces and Images responsibly, since the difference is simple--draw Surfaces rarely, modify Images rarely. In some engines like TurboSphere the difference is an important distinctions. In other engines it might not be, but it is then a relatively harmless addition.

EDIT:
I'm curious why you say that TurboSphere is overengineered. I certainly agree that it has a lot of NIH in it, and that the new drawing system is somewhat complex.

https://www.allegro.cc/manual/5/al_set_target_bitmap

The Allegro docs mention FBOs.  No PBOs to speak of.

Huh. If you want to modify what an FBO contains--for instance, to tell what the value a particular pixel is--you would still need to download it from the video card. If you modified a certain pixel, you could surely do that by a drawing operation, but as far as direct access and especially reading results into software, you face the same issues you would just using GL textures.

I'm curious why you say that TurboSphere is overengineered. I certainly agree that it has a lot of NIH in it, and that the new drawing system is somewhat complex.

I don't know, I guess because I'm of the KISS/YAGNI school of development, seeing you overthink all the new additions and agonize over how best to implement them makes me roll my eyes.  Just call it difference of opinion I guess.  I like to see results quickly and let the program develop mostly organically; I'm not afraid of a little refactoring if things start to get too hairy.

Huh. If you want to modify what an FBO contains--for instance, to tell what the value a particular pixel is--you would still need to download it from the video card. If you modified a certain pixel, you could surely do that by a drawing operation, but as far as direct access and especially reading results into software, you face the same issues you would just using GL textures.

That's the beauty of it though--the way Allegro is set up you very rarely have to cross the hard/software barrier.  The only time I ever lock a bitmap is to load an image from disk, otherwise I let Allegro do it all in hardware.  It's awesome that way.

Huh. If you want to modify what an FBO contains--for instance, to tell what the value a particular pixel is--you would still need to download it from the video card. If you modified a certain pixel, you could surely do that by a drawing operation, but as far as direct access and especially reading results into software, you face the same issues you would just using GL textures.

That's the beauty of it though--the way Allegro is set up you very rarely have to cross the hard/software barrier.  The only time I ever lock a bitmap is to load an image from disk, otherwise I let Allegro do it all in hardware.  It's awesome that way.

When you remove blit for Surface's, this is mostly how it works anyway. A Surface is used only sparingly in TurboSphere, mostly when you want to touch pixels very specifically and see the results directly. If you just load an Image directly, it works that way entirely.

The reason I want to do anything in software at that point, except for retrieving data, is that some operations don't lend themselves well to hardware acceleration. I found this when doing gradient munching squares, many bezier curves, and some procedurally generated effects. I had much better performance simple drawing directly in software.

I like this difference being exposed to script.

I'm curious why you say that TurboSphere is overengineered. I certainly agree that it has a lot of NIH in it, and that the new drawing system is somewhat complex.

I don't know, I guess because I'm of the KISS/YAGNI school of development, seeing you overthink all the new additions and agonize over how best to implement them makes me roll my eyes.  Just call it difference of opinion I guess.  I like to see results quickly and let the program develop mostly organically; I'm not afraid of a little refactoring if things start to get too hairy.

Fair enough

I like to test different implementations and try different solutions for every problem. Most of it probably is not really needed, and any of the possible solutions are suitable. But I like to have my own personal results in hand, as well as a few different attempts with different methods before I properly commit to something. And I like to talk through what I'm doing and share my findings along the way. Sometimes being able to look what I wrote and know that others will see it helps me see it differently myself.

I do take any additions to the native API very seriously, though. I am much happier with the generality and minimalism of TurboSphere's native API than Sphere's API. Since I implemented the Galileo API, almost all of my additions since have been to solve a particular problem I had trying to write demos.