LiveCode Forums

I have a simple question. If you make a game with a scrolling background, is it better to use a button or an image to display the background image?

I usually place two images side-by-side in a group whose width is smaller than the combined width of the images. Then I just set the hscroll of the group to simulate moving across the landscape.

If the imagery at right edge of the right image matches up with the imagery of the left side of the left image, the effect is a seamless never-ending scroll

I have always done it using images.

There is a simple lesson on how to do it at https://sites.google.com/a/pgcps.org/li ... ng-terrain

Thanks Cy - I'm already using your directions! LOL. I think I asked the wrong question. What I'm trying to figure out is if there are any advantages or disadvantages to using an image for background instead of skinning a button. I'm using buttons for everything else.

I'm trying to get a feel for what LiveCode is good at and bad at, so I can better design games that emphasize the platform's strengths and avoid its weaknesses. As you noted in your tutorial, it's tough to use intersect for baddies if you have a big huge scrolling background. I think I'd be tempted, if I'm doing an overhead shooter, to set the background to blue and make "islands" that move.

One thing I plan on doing is running some code on a variety of older machines to get a feel for performance on different computers with different processors. I've never seen any benchmark-type stuff for LiveCoders who want to make games. I'm convinced that there's a huge group of people out there, young and old, who'd love to make classic-style arcade games in LiveCode. But I don't need to tell you that! Your site and the BYU site are both great examples of how easy LiveCode is to use and how you can do so many things with it.

Many years ago I made a ruler, and on the slower machines of the day the rendering time difference between an image and having that same image displayed as a button icon noticeably flavored the button.

A lot's changed since then and I've not had occasion to test this in any version more recent than 4.0.

But give it a try and let us know how it goes, please.

Great idea. You are correct. Having benchmarks would be really useful. Students often have older/slower computers and cellphones. So we worry about size and speed of games.
We always used the 6x over the 7x and 8x versions of LiveCode for games because they were faster, less buggy and made smaller standalones. I wonder if that is true of the later 8x and 9x versions.

The same concern goes for the components you use. Images have typically been slower. I would assume that it is still true but what if they are on a button? Does it matter as much?

How you code is also important. In the early versions of LiveCode (6 and before), it was faster using the 'set' command to move an object. e.g. . The 'move' command was slower and you would never use 'relative' because it was too slow. e.g.. In later versions, I saw students using it successfully. So at some point, the code must have been optimized for that command.

Also, thanks for the kind words. It is nice knowing that someone is finding my lessons useful and feedback is always welcome. Too bad, I no longer have edit rights to it to make changes and improvements.

I am looking forward to your findings, especially with the stable version 9. I would not be surprised so see that version 6x is still the best for game development. It had a simpler interface, was solid, fast and a small footprint.

Thanks

I hadn't thought about using and testing different versions of LiveCode, but I will include that. I'd been using LiveCode Community 7 for a long time, but it was crashing a bunch on me with the animation stuff. I started using 8, which crashes far far less. Still need to try 9. So yeah, I'll do some tests with the different versions on different computers and see what happens.

Definitely try 9. Earlier versions are no longer being maintained, so 9 represents the current state of the engine and the baseline for all versions going forward.