Can a GS genius find a way to speed this up

colander

GS does not have a table display behaviour which is a real limit if you want to do business apps like events for racing, theatres, sports, etc.

I have been trying to get a table display to work with 17 columns x 350 rows. I started with @StormyStudio tabilizer but I couldn't get it to work well enough with a large table. I tried a combo of scrolling menu and tabilizer but still not good enough. @CodeMonkey god bless you made a major improvement with the spawner mechanics so I could display a larger table.

The attached table display takes about 1:40 minutes to load on an iMac, 3:15 minutes on an iPad Air and crashes an iPad 1 at about 1:00 minute. If anyone wants to use this with a small table it will work well. For the size I need the load time for iPad Air is not practical.

Something like this would be a great benefit to the section of the community writing business apps. I'm sure it could be used in games too in ways I can't think of.

Can one of you GameSalad geniuses work out a way to sup this up?

tatiang

Why are you trying to display a large table versus just displaying a few rows (a screen's height worth) at a time and allowing the player to swipe or tap a button to refresh the view and generate the next set of rows? I understand it might look a little better to allow the user to just swipe down a screen at their own pace rather than being bound by a set screen area... but is there another reason?

I haven't looked at the project file yet so sorry the answer is obvious when I do.

Also, have you looked at methods such as hyperloops that can spawn hundreds of actors in a second or so?

tatiang

Hmm... you're using an every 0.5 seconds timer to spawn your cells. That seems awfully slow. There's also the Fast For Loop explained at the top of this thread: https://forums.gamesalad.com/discussion/comment/446848/#Comment_446848.

TaoOfSalad

I suspect it's slow on devices and crashes on older hardware because having so many DisplayText behaviors active is eating up texture memory. If you wrap the DisplayText in a rule so that it is only active when the cell is actually visible on screen, then the engine will be able to manage texture memory better.

colander

@tatiang I have tried different times and it doesn't make any difference to the time it takes to spawn the cells until it gets to 0.6 secs on my iMac. I will have a look at the Fast For Loops method and see if it can do it faster.

Does anyone know if spawning nearly 6,000 instances is just going to take that amount of time no matter what I do?

@TaoOfSalad I will try that it should help with smoother scrolling but won't another rule add to the load time?

TaoOfSalad

It's going to require some experimentation on your part. I can say that the overhead of memory and computation for each active DisplayText behavior is almost as much as whole new actor, but only while it is active. And DisplayText particularly hits texture memory because each DisplayText allocates a separate texture whereas actors (and particles) can share texture memory if they have the same image. So for this particular algorithm, you're probably going to run out of texture memory and crash before you hit any other hardware limits. But the DisplayText texture is only allocated while the behavior is active, so it's something you can control.

tatiang

Spawning 6000 actors is just going to take a while. When I was working on my Study of Loops for the Spare Code thread, I was knee deep in the timing of various loop methods but I forget all of that now. I suppose I could go back and read my notes but my guess would be on the order of a minute on a device. In Creator, it can be done much quicker, probably 20-30 seconds. If you tinker with the Fast For Loop or HyperLoop, you can probably get it down below that duration. But it requires some pretty headachy coding (copying a rule set a bunch of times, etc.).

Using a Timer behavior to spawn 6000 actors is going to take more like 10 minutes.

RThurman

Hmmm.... Instead of having 50 spawning actors (and all that overhead), why not have one actor spawning fifty cells on each pass of a timer. Think of the savings in 'timer' code that would have on the size and efficiency of the project.

StormyStudio

Out of interest how did it run with my table-izer.

It should have done it pretty well... as it creates the set grid rows and columns of about 10 by 7... or what ever you choose for your scene. Then as you scroll it should update what each of those actors is displaying.

I've never tested a scene that size but seems odd that it would be much slower as each actor is only being told to display the given row and column value.

I'll try and take a look at your scene later...

The_Gamesalad_Guru

You'd be better of creating an indexing system to scan through the rows or colums. Changing what the set of actors displays imstead of 6000 actors. Reducing the time to nill.

colander

@StormyStudio your Tabilizer is great and works well but I can't get it to work smooth enough for release. I may not be adapting it correctly to my app so please have a go. At the moment I'm trying to get it to work like tshirtbooth's Multiscreen Menu video but the present system loads way to slow if at all on a device.

@RThurman I have played with this sometime ago now and I was spawning a 50 row by 17 column table. I found it loaded the quickest when compared to one or ten spawners but I haven't tried it with the bigger table.

@TaoOfSalad I tried only displaying text in the visible cells it still takes the same amount of time to load. Also it loses the smooth scrolling aspect, it has the same issue as Stormy's. More like a stop start affect as display text becomes active in cell off the screen making the whole thing stutter if that makes sense.

@tatiang over the weekend I am going to try and get Fast For Loops to work and see if it can lay it out quicker. This may all be for naught because a scene 7300 x 2048 with nearly 6000 instances might struggle to display and run smoothly no matter how it is done.

colander

@tatiang @TaoOfSalad @RThurman @StormyStudio I got Fast For Loops working try the attached game project. It is better but still not good enough for a release. I imagine smaller tables will work well but the size I need 350r x 17c is too big.

There is a row count displayed so you can see its progress. On my iMac it spawns 100 rows in 10 secs, 200 in 30 sec, 300 in 55 sec and 350 in 75sec. The longer it runs the slower it gets. It's an improvement of 25 sec compared to the spawners in my version.

It loads in 2 mins on an iPad Air a big improvement and crashes an iPad 1 at 95 rows in 45 sec. Please try it and see of you can improve it. I will also have a look at Hyper Loops.

@The_Gamesalad_Guru not sure what you mean. If it is changing the text in the cells as you scroll I have tried that but the effect is not as good as a floating menu system in fact it is kinda hard to look at and work with for any length of time.

The_Gamesalad_Guru

If you used scene wrap and had the actors scroll out the top and back up on the bottom you could have the text change when off screen and it would be populated with the new info when it appears back at the bottom. So essentially the loop would be the wrap or it's the actors looping not the table. When the actor reaches the top just off screen the index moves up or down one step.

tatiang

@The_Gamesalad_Guru said:
If you used scene wrap and had the actors scroll out the top and back up on the bottom you could have the text change when off screen and it would be populated with the new info when it appears back at the bottom. So essentially the loop would be the wrap or it's the actors looping not the table. When the actor reaches the top just off screen the index moves up or down one step.

Yes, this. Brilliant. I actually used the same idea for a Slider Puzzle template I made. It looks like you can swipe and scroll endlessly left or right but there are a limited number of actual tiles. Good thinking.

The_Gamesalad_Guru

This is why I'm a Guru...

colander

@The_Gamesalad_Guru I have started working on your idea but I am struggling to find a way to keep all the cells locked together as a block which can then be wrapped through x and y. Any suggestions?

@tatiang you have done this before can you help?

The_Gamesalad_Guru

Use scene linking and constrain them to a singe actor then just control the single actor the are linked to. This is how I do a keyboard that moves up and down with all the keys attached.

colander

@The_Gamesalad_Guru what is "scene linking"? Also the minimum size table I can use for this is around 1,000 actors (58r x 17c I need 58r to allow for zoom out) would all these constrained actors be able to move fluidly?

colander

I think I have a workable version now. I need to do some more work with it but it looks promising.

This version spawns 350 rows with 17 text displays, one for each column. This works thanks to the new features in text display.

I spawns them in 12 sec on an iMac 15sec on an iPad Air and crashes the iPad 1 in 15 sec at 150 rows. I will test it on a friends iPad 2 when I get the chance.

EDIT: Changed the iMac time to 12 sec not the 17 sec originally stated.

colander

Here is Table Display v1.00 for anyone who wants it. I left @ericzingeler logo and instructions in it as it is his Fast For Loops code that drives it.

The_Gamesalad_Guru

The_Gamesalad_Guru

If you use the method I layed out you will have no delay at all. As @tatiang expressed it is brilliant concept and will be fluid and instant with zero delay. If I have a chance I will do a prototype. 12 seconds is an eternity in game time.

colander

@The_Gamesalad_Guru I like the idea and I'm keen to pursue it. I have been thinking about it a lot and stared some experimenting. A prototype would be great to get me going in the right direction instead of up the garden path so to speak.