Game elements visibility in actual project

[lcs-rgordon]

Somewhat related to #140, this fork is my attempt to get the AsteroidBlaster game from the tutorial running in a standalone macOS app:

https://github.com/lcs-rgordon/ImagineEngine

I've tried to keep my commits atomic so that it's easy to see what I've done:

https://github.com/lcs-rgordon/ImagineEngine/commits/master

Doing my best to follow @JohnSundell advice from Twitter I'm using the AppDelegate to create a GameWindowController instance to launch the game:

https://mobile.twitter.com/johnsundell/status/951739402845384704

When the game window opens, the dark blue background is visible, and I've confirmed using the debugger that ImagineEngine is doing it's thing (for example, I can see that asteroids are spawning every two seconds).

However, the window only shows a dark blue background.

I'm betting I've missed something, but I've opened this issue in case there is something with ImagineEngine that could be fixed.

Forgive me if I'm not reporting this issue correctly, I'm a relative newbie at contributing to open source projects via GitHub.

[Alex]

Hey @lcs-rgordon, how are you?
Check this out (helped me a lot): Issue (#49)
I used the attaching to view solution so far for testing: 😅

[lcs-rgordon]

Thanks @Alex88WH , I'll try that!

I've also had a facepalm at my end – realized I had not added the image assets to the project.

I've now done that, but having the same results (solid blue screen) so I'm guessing the issue is that I haven't add (or named) the image assets correctly.

I'm off to work for a few hours but will keep working on this later today.

[Alex]

About loading textures (I had the same problem): Issue #88
Just use folder reference instead of groups. Hope it helps!

[John Sundell]

That's great advice @Alex88WH 👍 A debugging tip is also to enable the scene's texture manager to report errors, like this:

scene.textureManager.errorMode = .assert

That'll give you an assert if a texture fails to load that you can use to check if the file paths match 🙂

[lcs-rgordon]

Thanks for the quick replies and suggestions!

So, hmm.

I've added the textures into the project with folder references.

Logging when textures fail to load.

Confirmed that the images are there in the app bundle after compiling, but still seeing the same issue.

My students will really enjoy reading this thread some day (it will be good for them to see that everyone has lots to learn).

[lcs-rgordon]

As a follow-up, I thought it best to start fresh and I set up a workspace with a project for Asteroid Blaster to live side-by-side with the ImagineEngine project, rather than mashed together in a single project which wouldn't be the correct setup long term anyway.

I see the same results but have noticed something interesting (which was true in the old setup I had too).

The texture manager error logging reports not finding the Asteroid, Ground, and Explosion textures, but says nothing about the House.

I don't know if that's relevant but thought it worth pointing out.

I'm still probably doing something silly, but sharing this update in case there really is something to track down (a regression bug maybe?) with ImagineEngine.

Here's the project I set up for the Asteroid Blaster test that I've been running:

https://github.com/lcs-rgordon/AsteroidBlaster

[lcs-rgordon]

One final follow-up for now, I tried duplicating the setup of the original poster in #88 where it looks like the compiled ImagineEngine framework had been dragged into the project directly.

I've also tried the "attach to view" approach that @Alex88WH kindly suggested earlier too.

Same results in all cases, still see the blue screen with no textures loaded; same messages in the log. I'm running High Sierra 10.13.2 and Xcode Version 9.2 (9C40b). I'm really scratching my head here. 🤔

[Mattias Hagstrand]

Hi @lcs-rgordon!

I tried downloading your Asteroid Blaster test project and it worked fine for me, the textures loaded correctly.

Could it be that you are not using a Mac with retina display?

When a texture is loaded the scale of the display is automatically added to the name of the texture (if the scale is greater than 1). If you don't specify the scale the scale of the main screen is used. Try adding this line to print the scale of the display on your Mac:

print("Main screen scale: \(Screen.main?.backingScaleFactor ?? 1)")

You can also try to hard code the scale when you load the texture:

let ground = Block(size: groundSize, textureCollectionName: "Ground", textureScale: 2)

Note that if you hard code the texture scale the textures will have different sizes on different displays.

[John Sundell]

Oh that's a good one @mattiashagstrand, that's totally possible 👍 I think we only search downwards when matching textures. We should probably search upwards too!

[Guilherme Rambo]

Would be cool if we could store textures in asset catalogs as well 😇

[lcs-rgordon]

Hi @mattiashagstrand! Thanks for taking a look at this.

I am in fact using a non-Retina Mac (mid-2012 MacBook Pro).

And my students are all on 4-year old MacBook Airs at school, so they'll probably hit this issue as well.

The external monitor I'm testing on here is ultra-wide, but also not Retina.

The code you suggested:

print("Main screen scale: \(Screen.main?.backingScaleFactor ?? 1)")

Produces this:

Main screen scale: 1.0

Per your second suggestion I've set the textureScale for all textures to 2:

lcs-rgordon/AsteroidBlaster@01404f4

And, partial success! Here is what I see:

So, thank-you!

I have three questions remaining:

1. Anyone have thoughts about why the ground texture isn't looking quite right? It almost looks like the top and bottom textures have traded places.
2. @JohnSundell does your most recent comment suggest there's a change that could be made to ImagineEngine to account for non-Retina displays?
3. @mattiashagstrand I confess I don't quite follow the scaling and display resolution details, but I could imagine using an if-else structure whenever a texture is loaded as a workaround for now – so that if a non-Retina display is found (screen scale 1.0?) then load the textures with an explicit scale factor of 2, otherwise load the textures normally and let ImagineEngine work its magic?

Thanks everyone for your input as I work to understand how to build standalone apps with this framework. You have all been most welcoming! I know for sure I have students who are going to love using ImagineEngine.

[Mattias Hagstrand]

Hi @lcs-rgordon!

Great that you at least see more than a blue window now... :)

The strange ground textures were caused by a bug in the implementation of Block.
I have submitted a fixed for that in PR #148.

Regarding the issue with scales I think we should fix so that retina textures are loaded even if the current screen is not retina as suggested by @JohnSundell. I will see if I have time to take a look at it.

I also think that adding support for loading textures from asset catalogs as suggested by @insidegui would be nice. That would make things a little easier since asset catalogs handle scales automatically.

[John Sundell]

Awesome that we're making progress 🎉 This feedback is super valuable - it clearly shows improvements to be made in order to make the engine easy to use for everyone 👍

@mattiashagstrand Thanks for the fix, I'll take a look at it right away!

I've created issues #149 to address loading retina textures when a non-retina asset is not available and #150 to support asset catalogs in a nice way (it's technically possible to use asset catalogs already, but you have to manually create Image instances, so we can make it a lot easier!).

If anyone is up for helping out on #149 or #150, feel free to dig in 😄 Thanks a lot for all the reports and insight in this thread, it's really awesome 🚀