Yeah, on second thought, I won't be able to avoid manual annotation, because the tiles that need to be visible or invisible depend on the scenario.  Right now I just do what you said and organize tiles by hand into groups that fade in or out simultaneously.

Here's a couple references FWIW. 
http://justindjohnson.com/softdev/isometric-occlusion/
This guy uses collision areas to determine occlusion.  AFAIK his underlying data isn't 3D; it's just like a space shooter with funny-shaped buildings.

http://simianzombie.com/posts/2018/01/29/isometric-demo
This guy has a lot more rigorous approach and actually uses a Z-buffer to determine occlusion of moving objects pixel-by-pixel.  He even considers rendering the scene by raycasting into a voxel volume, which sounds rad.

I am keeping it slow & simple: breaking my objects into unit cubes and rendering back-to-front and bottom-to-top.

In isometric games, the scenery disappears or fades out when you walk behind it.  It looks like this is usually done by the level designer flagging certain tiles as "roof", "wall", or whatnot.  Anyone have more insight into how this is done in different games?  Is there perhaps an ugly but general solution that doesn't require manual annotation?

Is it frustrating to tell where everything is when playing isometric games?  How have the designers handled it?  I only ask because I haven't played a lot of them myself.

No way to have overlapping widgets, as you don't know during the intermediate call if there is a button to be drawn on top of you

Thanks! This is exactly the kind of thing I wanted to know.

I've used Dear IMGUI professionally, and in my own personal code at home, and have only good things to say.

Such as?

They seem like a good idea, but I haven't seen many complex or non-trivial examples.  Anyone here had experience using this design pattern and would care to elaborate?

I used to see these all the time from about 2000-2007.  Are they still being made?  And if not, what was responsible for the "golden age"?  I always assumed Flash must have had a really good interface between '00-07, but maybe I just got old and stopped going on Newgrounds.

https://github.com/nothings/single_file_libs#vectors

This is a goldmine, thanks.

Handmade math in C is good. There's also a good one by ferreira.

Thanks.  I usually look for libraries that have been used in Humble Bundle games, but I think most of them "roll their own" math functions.

I know there are a few good ones in C++ that use operator overloading.  I kind of like the functional approach, though. 

I am trying out G4L now, but I noticed that there are a couple other libraries out there.  Would appreciate any stories from people who have used them about what they liked or didn't like.

To me, it sounds like everything is based around safer concurrency, and he wants to be able to write blocks where freaky stuff is allowed to happen because the programmer personally knows it can be safely parallelized.  Take the exceptions, for example: it sounds like he is afraid of cases where an exception occurs in just one thread and messes up the game state...but if the programmer knows it's OK, it can be done.

Ditto for "lenient evaluation".  It sounds like he wants lazy evaluation to go into freaky programmer-approved blocks, and eager evaluation to be done by the compiler when it knows the value won't change.

And ditto for the "atomic" statement blocks and transactional memory.  Isn't STM working in some languages?  I thought that Clojure had it.

But I'm really shingling on the fog here...

Did anyone else read this?

https://groups.csail.mit.edu/cag/crg/papers/sweeney06games.pdf

There are some choices I don't quite understand, probably because they make sense only after one has done a ton of programming.  Like where he says "Only throw() constructs should cause an exception".  What do people with a lot of experience think about this?

From what I can remember:
-Every level has two songs associated with it.
-Both songs play in order from start to finish.
-If you die, the song that was playing when you died starts over from the beginning.
-After both songs have played all the way through, you never hear them again unless you restart the level.

Am I missing anything?

I read an article in a '90s computer game magazine about a game designed by (I think) Woody Allen.  The gimmick was that everything was based off the movement of a spinner.  There were levels where you use it to move back and forth, there was a rhythm level where you try to spin it at a given rpm, there was a flirting level where you use it like a volume knob to modulate whether you're "coming on too strong", etc.

Probably The Act, which was released a few years ago for iOS.

I might have asked this before, but it is driving me crazy.

I read an article in a '90s computer game magazine about a game designed by (I think) Woody Allen.  The gimmick was that everything was based off the movement of a spinner.  There were levels where you use it to move back and forth, there was a rhythm level where you try to spin it at a given rpm, there was a flirting level where you use it like a volume knob to modulate whether you're "coming on too strong", etc.

It might never have been released, but there were screenshots in the article, so I'm hoping someone else has heard of it.

Do you know where you're losing time? If you profile is the cause of performance issues drawing to your canvas?

I have no idea where the bottleneck is.  It is proportional to viewport size and not number of entities, so I assume it has to do with drawing to the canvas, but it could also be downstream of that (and out of my hands).  Just tossing this idea out there to see what my options are.

My motivation is that I have a game running with 2D unaccelerated graphics.  I have gotten to like it because it cuts out a lot of layers of lasagna code and simplifies the programming, especially for things like reflective surfaces or translucent objects.

It runs OK, but there is a noticeable drop in frame rate if I run it at, say, 1080p.  If I could halve the render time by multithreading, it would give me more wiggle room for other parts of the render loop where I don't want the extra code complexity.

Is there any fundamental reason why you can't, say, use 4 threads to render each quarter of the screen, and get a performance boost?  I'm talking about 2D graphics that are *not* accelerated by a graphics card. 

I guess each thread would need access to the game data (which entities are at which locations), and you would need to lock them until all of them were finished before you flipped the frame buffer.  But I haven't really thought this through.  Has anyone been down this road before?

The built in Binary serialization becomes tedious when you use inheritance a lot (which I did), and JSON.Net had problems serializing objects with circular references (which mine have).  I guess this is just a consequence of the way I wrote the game.  ATM I'm forging ahead with the custom serialization code.

I am writing some code to save/load game entities.  It is extremely tedious because I'm basically just going into each object and writing stuff like:

Code:

void save(BinaryWriter file){
  file.Write(intValue);
  file.Write(floatValue);
}

void load(BinaryReader file){
  intValue=file.ReadInt32();
  floatValue=file.ReadSingle(floatValue);
}

This is something the computer should be able to do, like pickling a class in Python.  And there is a way you can mark objects for serialization in C#.  But the automatic serialization looks as if it can be just as tedious under certain circumstances.  Is there anyone that has done this before and can comment on how it worked for them?

This is uncanny.  I have been working on my own game/engine in C# that borrows a lot from Flashpunk, and I just browsed over here looking for a better way to write events and event chains, wondering "how would Chevy Ray do it?"