OpenXTalk Forums

It's valuable to test the capabilities of a tool that you intend to use for a task before investing a lot of time into trying to use the wrong tool for the task at hand. OXT is no different.

I've read lots of people talking about how you can make games with only what the this xTalk Engine has to offer 'built-in', so where are they??? And where are the wikis and statistics about how to sync music and sound to animations, best ways to get smooth animations, or for layering sprites, or how many and what size of images can be moved around per-second etc. etc.

We need an honest assessment of what we can and can't do, at least as far as game development, regardless of the age group you might think that demographic of use is (I don't know about anybody else, but when I was 10 I was reading Compute! and Atari Antic magazines, and subversive underground comix books by people like Alan Moore). Once we have that we can figure out how we can improve on it, make libraries to make specific tasks easier, and/or add more capabilities through extensions or other external things.

So with that in mind, and inspired by Richmond's stack (but with no particular age parameters).
I started to test an idea that I've had for some time, using Isometric Animated GIFs as Sprite that can move in 8 compass directions.
I cut apart a sprite sheet found on Itch.io (https://engvee.itch.io/free-animated-is ... -hellbeast), but I could've easily made my own with something like MakeHuman : https://en.wikipedia.org/wiki/MakeHuman I actually did a bunch of that sort of things years ago when I was very interested in SecondLife / Open Worlds (SecondLife even had a Lua dialect you could script with!) The bottom 2 sliders controls can adjust some variables used in the animation, and the other sliders set many of timing related Engine Properties, but it doesn't use the accelerated rendering features (GPU acceleration with that is only available on specific platforms anyway). You can adjust to try to get a smoother walk around animation.

Also Mini-project experiments like this help to find the bugs (like the 'flip graphic' feature bug that wipes out frames of animated GIFs). You find bugs when you actually try to do different things with it, not by staring at code.

My experience with animated GIFs was pretty negative, that is why I fixated on PNG images: which, predictably, resulted in another set of problems.

richmond62 wrote: ↑Fri Feb 23, 2024 8:38 pm My experience with animated GIFs was pretty negative, that is why I fixated on PNG images: which, predictably, resulted in another set of problems.

Its probably worth investigating using a mix and match of the graphics features available 'built-in'

So let's take stock of what we have available:
Index Color, 1, 8, and 24 bit pixel bitmap image support that we can use in the Image classic control, which supports:
- PBM (including the ASCII TEXT version discussed in another thread), I believe this gets auto-converted to PNG formatted Data by the engine.
- PNG that supports 1,8, and 24 bit color plus 8-bit alpha channels transparency which means you can have 255 levels of opacity built in to your image).
- JPEG but only up to 24bit (sorry Printing Press people, no built-in CMYK support), and doesn't support alpha channel transparency at all, but it does support heavily compressed images ( both lossy and lossless).
- PNG which supports 1,8, and 24 bit color plus 8-bit alpha channels transparency which means you can have 255 levels of opacity built in to your image).
- GIF which is an index color format, support includes displaying animated GIF89a format files which you can loop of show individual still frames, but you can't: change the color table information nor edit the timing information of a frame within the animated GIF. As far as I can tell, there also no way to set image data for individual frames of an animated GIF. Those are things I want to add support for.
- SVG color scalable vector graphics can also be use with the image control (since LC CE v9 ) but first the SVG data needs to be converted to 'compiled drawing' data (which is not a documented format that I can find). 'Compiled drawing' data can be compiled using one of two handlers the IDE's in drawing library. This data is automatically compiled when SVG(s) are imported from the file menu. This SVG support does NOT support SVG features through, for one thing it will ignore embedded text /fonts (so convert font/text to outlines before exporting the SVG from your drawing app). Images with SVG data set to scale render faster than a bitmapped equivalent image and can be less data to store in memory (depending on the content).

In addition to SVG support that was added to the Image Control we have a few other methods for using vector drawing.
We have the classic Graphics Controls, which besides standard geometric shapes, can use arbitrary lines and shapes but only using straight lines between points, that includes circles and round rectangles when you get the 'effective points' of a graphics, it's graphic data boils down to lists of x,y points. The Graphics controls can be filled with gradients, which is nice, and you can edit the points via mouse control if the graphic is in edit mode. (which was broken in LC CE 9.6.3 but I got that working again in OXT DPE)

Then there is Widgets, SVG Icon and other widgets, can use SVG vector path data to draw shapes and lines, including smooth Bézier curves, with sub pixel precision (meaning I can render a line that is thinner than a single traditional pixel size of 72pxpi (newer, like 'Retina' or 8K -resolution monitors can have double or quadruple that amount of pixels per inch)

There was also an 'SVG View' widget that was never rolled into the IDE, that can render full color SVG files in a way that's similar to the 'classic' image control's support for SVG, but you can even use that widget with older LC CE v8 based engine that had no built-in color SVG support.

Good job! That stack is way overdue!

One thing you seem to have overlooked is a sequence of static GIF images, which might be a lighter thing than a sequence of equivalent PNG images.

richmond62 wrote: ↑Sat Feb 24, 2024 9:09 am One thing you seem to have overlooked is a sequence of static GIF images, which might be a lighter thing than a sequence of equivalent PNG images.

Why do you think I've overlooked that? Certainly GIF is lighter, less data for the engine, just based on the file format. PNG is going to be 24bits per pixel (32bits per Px if you have transparency/alpha channel mask), GIF is 8bits per px with a common 256 color defining table.

I'm using 8 animated GIFs here, one for each of 8 directions, each has 20 frame of walk animation.
If they were all separate image objects that would be 160 images in my stack. From my experience the more objects you're moving around and changing in real-time the harder it is for the Engine to handle it. Every try to make a grid of a lot of objects, let's say 128 columns of 64 (total 8192) buttons or graphic controls objects? It pretty much chokes the Engine, takes forever to even build the grid unless you lock the screen. To me that means less objects is better.

Things that could possibly make this walk animation smoother:
Adjusting the GIF's files built in frame delay(s) (all set at 5 when I built the GIFs).
Reducing the Amount of frames in the animation, 20 frames for this is probably overkill.
Reducing size of the 'Sprite' Gifs from 128x128 to smaller (can we at least match SNES resolution? Then you can let the Engine scale it up to full screen size like so:
set the fullscreenmode of stack to {empty|"exactFit"|"letterbox"|"noBorder"|"noScale"|"showAll";
set the fullscreen of stack to true
Remember we are all using displays now that have many times more pixels than when 1024x768 was the common standard.

What else could make this type of animation better?
I think loading individual frames into an Array in memory and then using the elements of that array setting the image data on a single Image object, that image control gets moved around while its contents get updated on a timer.

SVG compiled drawing would likely be faster drawing than the equivelant pixel data. Of course most sprite sheets you find on the internet are going to be bitmapped images, so one would probably need to create their own vector drawing animations to even test this theory. I have done similar speed tests with an SVG Playing Card Deck, rendering 52 SVGs to an image box took less than 500 milliseconds. See experiments here: https://github.com/PaulMcClernan/OpenXT ... ayLibMaker

But I also know that setting the contents an image control from bitmapped image data in memory has been pretty fast as well, at least for small images, because that's exactly how the core image filters demos in the OXT AppleImagineLib demo stack work. You pass the long id of an image and the extension grabs it's image data, passes it to core image filter and passes new data back which I then used in my scripts to set the image data for the same image control to the newly filtered data. It does this all at a pretty fast frame rate, synced to slider control, of course core image is likely using the GPU to do it's work on the image data so that helps speed wise, but the point is it doesn't take a lot of time to set the image data of an image control from data in memory.

I see two constraints for game dev with this engine: threads and frame rates.

Being single-threaded prevents even just interleaved instructions, and true concurrency is off the table.

With frame rates, LC had started down the road of a tile-based optimization, but IIRC the lead engineer noted that while it's a generally good approach for most compositing/buffering at systems, it's not very with-the-grain for Skia's rendering mechanics, so a different approach is needed. I believe that different approach has been slated in their queue, but along with other priorities. Safe to say it's not in the v9.x engine.

Safe to say it's not in the v9.x engine.

That I think should be obvious. But, whether it is in the 10, 11, or 12 engine will do us lot "beyond the pale" no good whatsoever.

SO, as far as I can see, there are 4 possibilities here:

1. Make what you can with what you've got.

(This IS, by-the-way, just fine for clones of "gubbins" such as Snail-Bob: and keeps the 9-12 year olds focused.)

2. See what gives with Malte Brill's animation engine, which he, out of great generosity, has released as an open source thing.

3. HACK the engine.

4. Tack on an animation engine from somewhere.

Personally I feel that #3 is far, far too much work.

Of course the 'Elephant in the room" is "Do we really think it is an important thing to make slick-N-sexy Warcraft clones in OXT?"

Having about 12 years of using LiveCode as a tool to introduce children to the principles of programming (what educators in Britain are wont to call 'computational thinking'), my answer would probably be 'Don't bother with either #3 or #4' as anyone (let's say my 9 - 12 year old victims once they grow beards) who REALLY wants to develop 'Warcraft clones' is just not going to bother with any form of xTalk.'

Almost half of the children who have attended my "Quick-N-Dirty" LiveCode sessions (At 4 hours a day, 4 days a week, for 3 weeks, they are nothing but "Quick-N-Dirty" : doesn't stop them from making Snail-Bob clones.) have gone on to get into the dominant programming languages/environments: they have all thanked me, saying that what I did with them was give them a big leg-up.

This is where people like xAction misread my intentions:

I have been using Hypercard-MetaCard-RunRev-LiveCode since 1993, and have NEVER had any illusions that it cannot be outstripped in almost every way by what are now the dominant programming languages/environments.

My "whinges" are exactly to do with that.

I really would be a 'big frog in a small pond' to believe otherwise.

Now, a few years ago, HyperCard was promoted as the answer to non-programmers who did not have either the time or the energy to do the seriously heavy lifting involved in learning one or more of the dominant programming languages/environments.

Is there any obvious reason why OXT should NOT be HyperCard's great grand-daughter, and, as such be "the answer to non-programmers who did not have either the time or the energy to do the seriously heavy lifting involved in learning one or more of the dominant programming languages/environments?"

I am not so stupid as to believe that the only significant people in the world are 9 - 12 years olds (though, now I mention it . . .): but I do believe that there are an awful lot of people, of all ages, who could find in OXT the tool they require, in exactly the way people found a tool in HyperCard: and that does NOT need slick-n-sexy animation engines.

#s 1 and 2 are related, and the practical focus. Not every engine is a game engine. OXT may be well suited for many turn-based strategy games, playing into its networking strengths while sidestepping the frame rates needed for dexterity games.

#3 is unclear.

#4 is where the old LC KS was headed with the discussion of a physics engine. While there are likely some good 2d embeddable engines out there, the cost of integrating them and building out syntax to interface with them via scripts would not be low.

For the moment, I feel networked strategy games offer the best opportunity to show off the current engine.

#3 is not only unclear, but a very unfortunate choice of words.

The word I used was to suggest that it would involve a violent and potentially disruptive overhaul.

However I have changed it for "fragile" types.

I updated the first post to include credit link for the sprite sheet I used for this test stack: https://engvee.itch.io/free-animated-is ... -hellbeast

This is a marvellous cross-platform tool for chopping up sprite sheets into individual images:

https://github.com/bmarwane/spriteSplitter

I am interested as to how one might use a sprite sheet inwith OXT without chopping it up.

I have been next door filing my teeth to sharp points.

- -
And got "all funny" looking at your cardScript because . . .
Looks all rather easy to understand, until, that is, one looks in button "WEST" and find it contains NO code.

Please, do explain.

Use the buttonss
or ArrowKeys to walk
the isometric DEMON_SPRITE
around on the stack window
in 8 different directions

There is NO indication as to which keys one might use to, say, send the Demon to the top, left.

FourthWorld wrote: ↑Sun Feb 25, 2024 5:27 pm #s 1 and 2 are related, and the practical focus. Not every engine is a game engine. OXT may be well suited for many turn-based strategy games, playing into its networking strengths while sidestepping the frame rates needed for dexterity games.

#3 is not only unclear, but a very unfortunate choice of words.

#4 is where the old LC KS was headed with the discussion of a physics engine. While there are likely some good 2d embeddable engines out there, the cost of integrating them and building out syntax to interface with them via scripts would not be low.

For the moment, I feel networked strategy games offer the best opportunity to show off the current engine.

I think this engine, even as it is, is capable of more than turn based, I'm convinced it can handle maybe SuperNES level 2D gaming even with the only two threads the engine uses. There's a few 'arcade' style genres that could be down with that.

There are two rendering libraries that are used, Cairo Graphics and libSkia, but it's not entirely clear which is being used for rendering which things in v9, but I'm fairly certain that libSkia is used for Widgets, but before that addition it was all Cairo Graphics lib (for the 'Classic Controls' which would include Image controls). From what I've gathered GPU acceleration that both of these renderers can use, is only implemented on for certain platforms (via OpenGL).

One thing I am sure of is that something changed about the way things render between 9.5.1 and 9.6.3, I'm not sure if it was an improvement or a degradation to performance, but it certainly has altered the behavior or frame-rate of animated stacks. Maybe it was more tile based optimization, but they initially added that long before 9.6.x (I mean when the syntax compositorTileSize was originally added).

As far as concurrence and threading, I already know that it is possible to add some sort of engine that makes its own threads, because I've already done that with that FluidSynth library, it use GLib's GThreads to make its own multithreaded sound playback engine, so it can play MIDI files using lots of sound samples in the background all day long without any noticeable effect on script execution speed.

Ah: press 2 arrow keys at once.

That should have been made explicit.

Ah: Behaviour scripts.

What is the advantage of using a behaviour script than a 'normal' script?

richmond62 wrote: ↑Sun Feb 25, 2024 6:32 pm This is a marvellous cross-platform tool for chopping up sprite sheets into individual images:

https://github.com/bmarwane/spriteSplitter

I am interested as to how one might use a sprite sheet inwith OXT without chopping it up.

Cool. There's probably lots of tools for doing this, I used Photoshop's Divide Tool to split them, you only need to know the amount of rows and columns in the sheet as long as its evenly divided for each frame, then you can export is as a batch of individual files. You can do the same (and a lot more) with the popular free ImageMagick library and command line tool.

You could probably use an uncut sprite sheet inside a group control to crop the image to the frame you want.

I used Photoshop's Divide Tool to split them

I would always favour an open source option if one existed (and not just because of the price).

You could probably use an uncut sprite sheet inside a group control to crop the image to the frame you want.

But at a coding overhead to the OXT user.

richmond62 wrote: ↑Sun Feb 25, 2024 6:56 pm Ah: press 2 arrow keys at once.

That should have been made explicit.

Ah: Behaviour scripts.

What is the advantage of using a behaviour script than a 'normal' script?

I didn't think it needed to be said that diagonals would have to be a key 'chord' (up+right to go north-east), but maybe I should've made that clear.
There's graphical arrow buttons to provide mouse down control it too.

The advantage to using a behavior script was that I didn't have to copy/paste that script 8 times, every time I wanted to change something in the script.

richmond62 wrote: ↑Sun Feb 25, 2024 7:20 pm

You could probably use an uncut sprite sheet inside a group control to crop the image to the frame you want.

But at a coding overhead to the OXT user.

But Groups controls seem to be optimized for this sort of thing, scrolling images (and other content), and so it might me worth the extra coding effort. Groups can have their layer mode set to "Static","Dynamic","Scrolling",or "Container", I don't know what is best setting for any particular use case.