He's being coy so you get him out

It's totally not impossible though Polycount forums have a very good example of click-to-maximise images, which keeps unruly 1080p images in line.

use the width tags, like so

the "click to view" thing works the wrong way imo, doesn't give an overview as the default, which is unfortunate.

Either way, interesting effect. Don't be afraid to get a bit of colour in there.

Glad to hear it Have fun with love, I miss it from time to time and it's nice to see how well it's grown. Can't stomach the thought of writing a big game in Lua these days though, haha.

While I'm sure you've read and are referencing it, just in case there's a reasonably comprehensive guide here. Once you've got your modified plist it's literally a matter of copying a renamed zip (your .love file) into your resources folder of a pre-prepared app, which isn't so hellish

Yup, looks great exactly the kind of thing I like to see/play on mobile, I feel the platform(s) at the moment suit games friendly to fingers, easy to pick up and undemanding about play-time best, and from the gifs I've seen this seems to tick those boxes.

One thing I'd like to mention is you might want to clean up those "perfect molecule" in "90 seconds" images a bit - at the moment they're very square and don't interact with the game space at all - a shadow or slightly smoothing the edges could work wonders imo.

Convert them to oggs then. ogg vorbis is compressed.

@superdisk - "every way" leaves you open to issues like lacking hardware decode support fwiw I'm very pro-ogg but superiority is a relative thing.

Mine's the one that looks a bit like a testicle It is a very friendly testicle though.

Jesus.

Happy to help.

That's correct. Tips would be to not do everything in scripts if you can help it because the speed gap is unexpectedly large. Cache script contexts where possible (the AS docs were ok at explaining that when we were implementing it). If you can keep the number of script calls down too, that's good - just getting into and out of AS is like 4 function calls deep. If you can batch calls (like, if 50 objects all have the same script on them, call it for all of them rather than burying some loop over all your attached scripts in update) then that's also something you should consider strongly. Basically be very wary of performance if you're going to continually scale your game up like we did, haha.

The best thing about AS is how quick it is to bind. We had a thousand or so functions and data members to bind, so Lua's manual binding would be a no go, meaning we'd have to go the swig route or similar, which is another dependency - that was the main driving factor behind the decision, the other one being static typing and C++ alike syntax.

Listening to metalstep, drawing and coding some space game shit for one of my last subjects of uni for the forseeable future So close to able to focus properly on work I can taste it.

Fwiw there are ways to force inlining on each major compiler, and building a nice macro to put the right identifier for your compiler in, and default to "inline" isn't hard.

 Re: the function pointers there, I'm not concerned about whether the compiler will want to inline or not for a given case, but whether it would be able to given that (as far as I can see) they are decided on locally and passed out of the ternary as function pointers. I realise it's a very local transformation but I'm curious how well that construct would optimise in practice.

Hahaha, I actually considered going that route but I'm not sure the functions can be inlined there if necessary. If someone knows concrete details for any compiler let me know but as far as I can see semantically you're treating them as function pointers there, albeit deterministically. Certainly very terse though, the OR is a nice (if fragile) touch.

But it creates a global anyway! Doesn't polute the namespace I guess but it's not concurrency safe, invokes overhead each time the function is called and isn't a usable pattern for anywhere you may need to compare nulls - the last one not an issue for qsort etc but prevents it from being a general-use comparator. It's certainly an interesting way of doing it while getting around the interface requirement, but I'm not sold on it As you said, could be accomplished in other ways.

Of course, but it's a shame to have to write that kind of code with extra wrappers to set static variables in your search function. I used the word gruesome because the author did, not to be hyperbolic - I'm talking about the mode setting code at the start of the function that relies on NULL signalling to set or get a static variable storing the mode, not the switch itself. I hope that was clear.

http://pigeonsnest.co.uk/stuff/pigeons-device.html

Today I learned. I wonder how (badly) this kind of thing interacts with modern CPUs. The gruesome hack is certainly unfortunate.

Of course, but in that case wouldn't mind the #ifdefs.
That kind of code ("get the pictures folder on this platform, or a fallback inside appdata or whatever") is kind of on the border between application and engine/backend/core/whatever, but I'd say more towards the latter - it's going in with your file operations, which are also generally reasonably low level.

I'd potentially consider splitting out your file operations to an internal (static) lib to be maintained over time and reused between projects, though a header and implementation file is of course ok too.

...This is quite the tangent, haha

@Boreal - perhaps more readable? certainly terser

Code:

result = (!mode && test(a,b) || mode == 1) ? foo(a,b) : bar(a,b);

I'm a bit of the first and the last I've been working in a big codebase with far too much preprocessor code for years, but I've been writing a fair bit of C recently where it's more commonly used in less evil ways I still prefer #pragma once to include guards though.