-
Sounds promising. I'll have to try that. Though I probably have like a hundred start of frame events that I'd have to change :o
-
Ah, that will be a pain,
I've abused "start of frame" events as well, but then found that using "run this event once"
(and placing events in the correct order of course)
allows for a more flexible control of event flow,
i.e. later on you can put those events in a group and postpone the execution if needed
or you can "counterize" your engine workings
i.e.
counter = 1 >> load level
counter = 2 >> create enemies
etc.
this is particularly useful when your game is complex and has various strictly-defined phases
while when using "start of frame" you are bounded to run those events "all together" and "just in that particular special moment"... XD
-
1 Attachment(s)
You can also use a group with a bunch of stacked Always events, with the last one closing the group for neatness for all your "startup" stuff! (my personal method :P)
About the topic at hand though: I was so curious so I made an attempt to use Schrodinger's method, by breaking up a 10 layer nested loop similar to the kind you would use to load tiles from a level editor array. Excuse how unintelligable and lazy everything is - i'm running on little sleep right now - but it should be a decent example: EDIT (forgot some stuff, new file) Attachment 20951
I made sure to scale and angle the loaded tiles and run a foreach loop on them randomly to fake hangups you might find in a traditional game. Run the second frame "all at once" and watch how long it hangs. Then run "spaced" and check out the difference.
Depending on how convoluted your current system is (very in my and most likely schrodinger's cases XD) you'll need to work on your method a bit to be happy with how you "space" your loading out. My system isn't meant to be modified and implemented, more just a simple mockup for proof it works. I could easily see something like this causing headaches if I needed an animated loading screen in any of my projects!
(I just realized I own a toaster so this might not hang nearly as bad on your end X) . Might need to further burden the loops! An easy way would be to copy the lines in the "burden" section a few times)
-
Awesome, thanks for making it an example Casleziro,
I'd definitely do something like that if/when needed in my convoluted projects XD!
Btw, had another idea, maybe a bit simpler and possibly a little bit more flexible,
just made a quick test and seems to work... you can actually use a sub-application for your loading bar,
it seems that (although a bit slowed in some of my very quick and definitely not thorough testing) the runtime of the sub-app doesn't get halted while the main app is looping
so you could i.e. display an infinite loading "circle" in the sub-app (those hateful things that keep spinning without telling you how much you'll have to wait XD)
and destroy the sub-app when done loading,
or even do fancy things like sending your "progress status" to the sub-app through shared values and make smooth animated progress bars
(like bars growing to destination instead of hard-steps, without having to wait the frame cycles you would need to play that animation in the main app)
-
Thanks for the example casleziro!
Schrodinger, that sounds awesome. I'm going to have to try that. Sounds like "problem solved"!
-
Uh - cancel that, sorry guys, looks like I was wrong!
In previous testing I mistakenly plugged the sub-app in one of those very convoluted projects,
and I forgot I was already "splitting" loops (for other reasons)
...the sub-app actually played only when I was stopping the loop in the main app :(!!
Tried plugging a sub-app in casleziro example ("all at once" frame) and in fact the sub-app halted there too until looping was done.
Sorry for the mess :(:(
******* EDIT *****
just to add some other mess,
you can actually do something like that, but in a very unclean way:
1) build "loading animation" as a stand alone application (maybe with same background color, or very small window area, no header/ thick frame etc., just to blend it with the background and make it look like part of your main app)
2) in main app, execute external program "loading animation" when needed
3) in main app, pass loading status to external file (es. ini) so that "loading animation" knows how to update / when to close
disadvantages: (beside most obvious awkwardness..) not very solid unless you do some hacks
(like adding a window control object with "set window topmost" in order to not lose focus)
maybe also AV softwares don't like you calling external softwares from your app, not sure if this could cause some issues
advantages: can do "cross-frame" loading XD
-
Kind of off topic, but I use solid colors to mask loadings. My game will fade to a solid color, I pull the level switch, and then alpha all the objects in. It's nice and smooth and really hides some of the rough edges.