Albrook is a hell of a map, I even remember having trouble getting miniSphere to load that one properly.

So my current theory is that my turning the tileset into a single strip, 32,480 pixels wide and 16 pixels tall is the problem.

@Fat Cerberus do you know of a hard limit on sizes of surfaces that can be handled by miniSphere?

(I construct the map by loading all of the tile images out of the data file and then drawing them on to a surface which I convert to a texture then use as an atlas with which I texutre one shape the size of a tile which then draws onto a large surface the size of the whole map.)

But I get nothing but black, I checked the images coming in and they seem ok, I tried converting the surface to a texture and blitting it with prim and I get nothing, if I do the same with South Figaro (and it's sensibly sized tileset) the blit draws the tileset onto the screen fine.

UPDATE... see attached.

I dropped the combining the tileset step and the load time went way up (retexturing the tile shape once per tile to draw per layer (i.e. a bazillion times...) takes a while) but now it actually works.

So I think I'm right on the surface size limitation I guess I could tile them in a rectangle rather than a straight line - a straight line just made the sums easier.

miniSphere doesn't impose a hard limit on texture size, but not all GPUs like huge textures.  What you want to do is construct a square atlas by taking the ceiling of the square root of the number of images (that's a mouthful! ) and use that value for both the X and Y sizes:
https://github.com/fatcerberus/minisphere/blob/v4.8.4/src/minisphere/atlas.c#L59

The correct U/V for a tile is then easily calculated by simple modular division:
https://github.com/fatcerberus/minisphere/blob/v4.8.4/src/minisphere/atlas.c#L95-L109

miniSphere doesn't impose a hard limit on texture size, but not all GPUs like huge textures.  What you want to do is construct a square atlas by taking the ceiling of the square root of the number of images (that's a mouthful! ) and use that value for both the X and Y sizes:
https://github.com/fatcerberus/minisphere/blob/v4.8.4/src/minisphere/atlas.c#L59

The correct U/V for a tile is then easily calculated by simple modular division:
https://github.com/fatcerberus/minisphere/blob/v4.8.4/src/minisphere/atlas.c#L95-L109

Thanks for the suggestion, I was already planning something like that - doing it now, I only did the simple maths version because I coded the original implementation of this in the middle of the night.

I don't think I would have thought of using modulo though, I would have done divisions and extra floor-ing; modulo is definitely more elegant.

Thanks for the suggestion, I was already planning something like that - doing it now, I only did the simple maths version because I coded the original implementation of this in the middle of the night.

I sympathize 100%!  This is pretty much the entire story of miniSphere 1.0 development.

OK after messing with several typos that now works but for some reason the night sky layer isn't drawing, I get all the other ones though...

Going to take a pause from compatibility and re-do how I draw maps, using the map as an atlas to texture a shape the size of the screen seemed like a good idea but I think it may be causing problems.

Going to take a pause from compatibility and re-do how I draw maps, using the map as an atlas to texture a shape the size of the screen seemed like a good idea but I think it may be causing problems.

Ok, this is done and a graphical anomaly I was seeing before has gone which is nice - I was seeing ripples on the screen from time to time under the previous drawing method - assumedly some side effect of constantly moving such a massive texture around on a shape, drawing the whole map and just moving it so only part is on screen seems to have removed this issue.

EDIT: spoke too soon, the shimmer/ripple is still there, I wonder if it's an issue with how allegro interacts with my screen or something.

Note sure if it's an issue with my computer or a miniSphere issue, could someone else test this and see if they get a shimmer on the screen as they walk: https://www.dropbox.com/s/lm3wsewvkaeuxss/sengine.zip?dl=0

License notes:
- sprite used for demo purposes made with https://github.com/jrconway3/Universal-LPC-spritesheet and are licensed CC-BY_SA, I'm not currently intending this to be distributed so not giving full credits
- map used in the test is pinched from Kefka's Revenge
- code is mostly mine with a few bits that are Fat Cerberus' + the Scale2x shader is based heavily on this: https://gist.github.com/singron/3161079 (no license is given), as with before this isn't really ready for use, pease test it and delete it for now

(Note obstructions are turned off in this test copy)

Are you sure the ripples are not just screen tearing?  miniSphere doesn't attempt to vsync.

Are you sure the ripples are not just screen tearing?  miniSphere doesn't attempt to vsync.

it could well be screen tearing not an issue I'd thought of, I will check later if dropping the FPS helps.

Is there a facility to turn on vSync or fake such from JS in minisphere?

If it doesn't already exist could we have a screen.naturalFR or something that gets the refresh rate of your screen so you can do screen.framerate = Math.min(screen.naturalFR,60) or something like that in order to turn on vSync?

I'm not sure if Allegro has any ability to use vsync, I would have to check.  It's not enough just to set screen.frameRate to match the monitor refresh, you also have to hold off flipping the backbuffer until you get a vsync signal, otherwise it eventually drifts out of sync.

Does your graphics driver have any ability to force vsync?  You could enable that and see if the ripples go away.

Adding:
al_set_new_display_option(ALLEGRO_VSYNC, 1, ALLEGRO_REQUIRE);
As row 92 of screen.c does seem to have improved the ripples issue, there are still some shimmers.

I think they may be related to drawing a map scaled at what is likely a non-integer scale and moving it around fairly fast.(My test demo has zoom in and out keys which are probably just a bad idea )

There is no graphics setting on macOs to turn on vsync, in some areas macOs is great, in having simple access to some settings it really isn't .

Hmm no, further testing with no zoom, movement speed decreased and vsync on (via the code above) still shows some shimmers.

I see it now too, it's especially noticable on the sewer grates and staircases.  I think a lot of it is just an optical illusion due to the band-like patterns, I've even noticed similar artifacts in the actual KR when moving around.  I wouldn't worry about it too much.

I did get a glitch where on one launch it didn't draw anything, so it's not just you.  Haven't reproduced the segfault yet, but I'm pretty sure I know what causes it at least.

Hmm yeah, I've just tried playing KR with the screen res increased and such blurriness became common.

Though I also think it was worse before I put vSync on.

Anyway I'm going to put that to one side now and aim at having a usable release of this code within 1 week.

It won't have everything but it should have enough to be considered a full map and sprite engine, current plan for first release:

- map and sprite loading and displaying including full support for v1 formats and partial support for new formats (+facility and notes on how to add formats)

- collisions using tiles or polys, note, poly mode will only support rectangles and circles for now but will allow each object to have any number of either/both of those

- map and sprite scripts including scripts to activate in meeting certain conditions or colliding with something etc.

- movement and camera control