OpenXTalk Forums

Posted: **Sun Nov 10, 2024 4:22 pm**

I am going to go through the stages of making a keyboard, and/or, mouse controlled game in OXT.

For this I shall use Open Source resources from Battle for Wesnoth: https://www.wesnoth.org/

Free troll sprites from: https://craftpix.net/
-

: 2D-Game-Troll-Free-Character-Sprites-720x480.jpeg (138.95 KiB) Viewed 1371 times

-

: Free-Robot-Sprite-720x480.jpeg (112.02 KiB) Viewed 1371 times

-

: island-boy-character-free-sprite-1.jpg (122 KiB) Viewed 1371 times

-

GIMP: https://www.gimp.org/

and, of course, OXT Lite.

Posted: **Sun Nov 10, 2024 4:39 pm**

I will START the game with a plain grass background exported from Wesnoth and then reduced to 50% of it size.
-

: grassSample.jpg (4.89 KiB) Viewed 1370 times

-
Craftpix sets come in extremely generous ZIP files with images at vast sizes and in all sorts of poses:
-

: trolls.jpg (194.88 KiB) Viewed 1370 times

-
I shall select the sequences I wish to use and resize them to 10% of their original size.
-

: Walk_004.png (12.38 KiB) Viewed 1367 times

-
I shall rename them for my own requirements.

Posted: **Sun Nov 10, 2024 5:04 pm**

We can start things rolling by finding out how to animate a character in a game.

I have started with a simple stack, a contrasting background image and a series of still images derived from Craft Pix images.
-

: Screenshot 2024-11-10 at 19.01.18.jpg (237.77 KiB) Viewed 1364 times

-
What I now need is a 'frame' to exhibit these images within:

https://en.wikipedia.org/wiki/Multiplane_camera
-

: 440px-Lotte_Reiniger,_Carl_Koch,_Walter_Türck,_Alexander_Kardan.jpg (79.55 KiB) Viewed 1347 times

Posted: **Sun Nov 10, 2024 5:36 pm**

Let's drag a Rectangle Graphic from the Tools palette to our stack:
-

: Screenshot 2024-11-10 at 19.31.05.png (66.16 KiB) Viewed 1358 times

-

: Screenshot 2024-11-10 at 19.36.32.jpg (238.11 KiB) Viewed 1358 times

-

: Screenshot 2024-11-10 at 19.38.21.png (241.19 KiB) Viewed 1357 times

-
You will see that I have:

1. renamed the rectangle graphic to 'gFRAME'.

2. made the rectangle graphic transparent.

3. made the border of the rectangle graphic have a width of 0 do it is invisible.

Posted: **Sun Nov 10, 2024 6:23 pm**

Here is a simple right-to-left animation controlled by the 'a' and 's' keys:
-

: Screenshot 2024-11-10 at 20.20.57.jpg (265.06 KiB) Viewed 1350 times

-
The card Script is this:

Code: Select all

on keyDown
   put empty into fld "fTRAP"
end keyDown

on keyUp QUAY
   if fld "fTRAP" contains "x" then
      -- do nothing
   else
      if QUAY is "a" then
         if the left of grc "gFRAME" < 80 then
            --- do nothing
         else
            put fld "FRM" into FRMX
            if FRMX < 9 then
               put (FRMX + 1) into fld "FRM"
               put item 1 of the loc of grc "gFRAME" into LATERAL
               put item 2 of the loc of grc "gFRAME" into ALTITUDE
               subtract 40 from LATERAL
               set the height of grc "gFRAME" to the height of image ("T1L0" & (FRMX + 1) & ".png")
               set the width of grc "gFRAME" to the width of image ("T1L0" & (FRMX + 1) & ".png")
               set the backGroundPattern of grc "gFRAME" to the ID of image ("T1L0" & (FRMX + 1) & ".png")
               move grc "gFRAME" to LATERAL, ALTITUDE
            else
               put -1 into fld "FRM"
               put fld "FRM" into FRMX
               put (FRMX + 1) into fld "FRM"
               put item 1 of the loc of grc "gFRAME" into LATERAL
               put item 2 of the loc of grc "gFRAME" into ALTITUDE
               subtract 40 from LATERAL
               set the height of grc "gFRAME" to the height of image ("T1L0" & (FRMX + 1) & ".png")
               set the width of grc "gFRAME" to the width of image ("T1L0" & (FRMX + 1) & ".png")
               set the backGroundPattern of grc "gFRAME" to the ID of image ("T1L0" & (FRMX + 1) & ".png")
               move grc "gFRAME" to LATERAL, ALTITUDE
            end if
            put "x" into fld "fTRAP"
         end if
      end if
      ----
      if QUAY is "s" then
         if the right of grc "gFRAME" > 1120 then
            --- do nothing
         else
            put fld "FRM2" into FRMZ
            if FRMZ < 9 then
               put (FRMZ + 1) into fld "FRM2"
               put item 1 of the loc of grc "gFRAME" into LATERAL
               put item 2 of the loc of grc "gFRAME" into ALTITUDE
               add 40 to LATERAL
               set the height of grc "gFRAME" to the height of image ("T1R0" & (FRMZ + 1) & ".png")
               set the width of grc "gFRAME" to the width of image ("T1R0" & (FRMZ + 1) & ".png")
               set the backGroundPattern of grc "gFRAME" to the ID of image ("T1R0" & (FRMZ + 1) & ".png")
               move grc "gFRAME" to LATERAL, ALTITUDE
            else
               put -1 into fld "FRM2"
               put fld "FRM2" into FRMZ
               put (FRMZ + 1) into fld "FRM2"
               put item 1 of the loc of grc "gFRAME" into LATERAL
               put item 2 of the loc of grc "gFRAME" into ALTITUDE
               add 40 to LATERAL
               set the height of grc "gFRAME" to the height of image ("T1R0" & (FRMZ + 1) & ".png")
               set the width of grc "gFRAME" to the width of image ("T1R0" & (FRMZ + 1) & ".png")
               set the backGroundPattern of grc "gFRAME" to the ID of image ("T1R0" & (FRMZ + 1) & ".png")
               move grc "gFRAME" to LATERAL, ALTITUDE
            end if
            put "x" into fld "fTRAP"
         end if
      end if
   end if
end keyUp

Stack deletedas better version now available.

Posted: **Mon Nov 11, 2024 12:40 am**

I have a TON of assets I have purchased for this exact thing.

... you're teaching me something I wanna DO, here.

Can we add controller support? Just a thought... and a question to multiple people.

Posted: **Mon Nov 11, 2024 7:51 am**

Can we add controller support?

Thank you so much for "rising to the bait".

If by controllers you mean these kinds of things:
-

: Devices.jpg (80.17 KiB) Viewed 1312 times

-
4 out of 7 of my 'devices'.

then they ALL send rawKey signals to both MacOS and Linux (and,I assume Windows).

I am, however, going to take a discussion about input devices to a different thread.
------------------

Oddly enough

having stated the above, the 2 devices on the left are NOT sending detectable key signals via MacOS 15.2.

Posted: **Mon Nov 11, 2024 9:42 am**

HOWEVER,in the light of this:
-

: DELUX.png (207.19 KiB) Viewed 1307 times

-
It might be sensible to change the RIGHT animation to the 'd' key.
-

: SShot 2024-11-11 at 11.48.24.jpg (165.18 KiB) Viewed 1304 times

-
Stack deleted as better version now available.

Posted: **Mon Nov 11, 2024 9:56 am**

However, the example is 2 dimensional and fairly boring.

So, here is another stack where the troll will move to wherever you click (with a mouse) in the stack:
-

: SShot 2024-11-11 at 13.38.44.jpg (255.55 KiB) Viewed 1297 times

Posted: **Mon Nov 11, 2024 4:40 pm**

Feeling frolicsome:

Code: Select all

-- skipping --
      if Quay is "w" then
         put item 1 of the loc of grc "gFRAME" into LATERAL
         put item 2 of the loc of grc "gFRAME" into ALTITUDE
         put (ALTITUDE - 25) into ALTITUDE
         move grc "gFRAME" to LATERAL, ALTITUDE
         put (ALTITUDE + 25) into ALTITUDE
         wait 10 ticks
         move grc "gFRAME" to LATERAL, ALTITUDE
         put "x" into fld "fTRAP"
      end if

-

: SShot 2024-11-11 at 18.38.16.jpg (178.5 KiB) Viewed 1284 times

Posted: **Mon Nov 11, 2024 6:27 pm**

Could you adjust to use non-blocking repeat loops, as these will currently block subsequent input until the character has finished moving.

Posted: **Mon Nov 11, 2024 7:08 pm**

That will ONLY be necessary when I start work on the proper game stack.

The stacks I have uploaded are JUST pedagogical things to show a few ways to animate a 'troll'.

Certainly non-blocking is necessary when, for the sake of argument a troll is chasing a robot, and while the robot is jinking around according to some semi-randomised something our end-user/gamer is trying to clobber it with the troll.

Posted: **Mon Nov 11, 2024 9:25 pm**

Let me know when you spin off that "controller" sub-thread. You've got some fairly standard stuff there... some a bit more esoteric, but hey, controllers are "USB human input devices" so surely, there's got to be some standard we can code against.

... surely?

Anyway I'd like to follow that, and I'm following right along with this, too. MANY thanks for writing it!

Posted: **Mon Nov 11, 2024 11:29 pm**

Started this controller thread, as I originally hijacked Richmond's post. Instead, I've moved the posts here.

Posted: **Tue Nov 12, 2024 7:46 am**

If by 'hijacking' you end up developing gamepad controllers, then hijack away to you heart's content.

The fact that I cannot, at present use this with OXT on MacOS 15 is annoying:
-

: Esperanza.jpg (20.89 KiB) Viewed 1214 times

-
after all, it cost me £5.

AND if you are hard put to imagine any advantage to living in Bulgaria, over, say, England: look no further than Amazon:
-

: EsperanzaUK.png (63.59 KiB) Viewed 1213 times

-
That IS, of course, the ONLY reason I live here: cheaper gamepads . . . ROFL.

HOWEVER: having 'hijacked' this thread: it will now degenerate into not just a simple instruction thread, but full-on nausea.

As OXT is NOT multithreaded, to effect

non-blocking

one has to use

Code: Select all

without waiting

which is NOT mentioned in the Dictionary, but SHOULD BE.

The next stack will feature:

1. A 'person' who moves independently of the end-user.

2. A 'person' that is controlled by the end-user.

And neither of these 'people' should block the movement of the other.

Posted: **Tue Nov 12, 2024 8:27 am**

At the time (a couple of years ago), that Saitek controller was off a car-boot sale. It cost me all of £1 in a box of assorted computer bits. I actually got 2 for £2 (they didn't even offer me a discount for taking both of them!)

...not that I'm still bitter about it at all you understand...

richmond62 wrote: ↑Tue Nov 12, 2024 7:46 am ...As OXT is NOT multithreaded, to effect
non-blocking
one has to use
Code: Select all
without waiting

You don't have to use that at all. In fact, it is multi-threaded. There's multiple rendering, processing threads etc.
However, send [thing] to [somewhere] in [x] milliseconds will achieve what you want without using hardcoded repeat loops - and wait statements in animation are just a bad idea.

See the 'shufflepuckery post' for example stacks of how it's done if that helps.

Not that I'm trying to tell you how to do it mind... each to their own.

Incidentally, the "without waiting" is detailed in the dictionary:

: without.png (92.21 KiB) Viewed 1199 times

Posted: **Tue Nov 12, 2024 9:59 am**

That's very queer as I could not locate 'waiting' yesterday.

In fact, it is multi-threaded.

What is 'it'?

LiveCode, at least, is not multi-threaded.

wait statements in animation are just a bad idea.

Not if they are being used in demonstration stacks so that learners can get a chance to see what it going on.

Teaching xTalk and Using xTalk do not always use the same considerations.

Posted: **Tue Nov 12, 2024 12:10 pm**

richmond62 wrote: ↑Tue Nov 12, 2024 9:59 am Teaching xTalk and Using xTalk do not always use the same considerations.

"Mean what you say and say what you mean"? or "Do it differently, not as I've shown you." - so what's the point in teaching a method that is not going to give the desired results?

If this is supposed to come under the 'teaching' category, I'll move it to the education section. That way it'll free up the "discussion" section... for discussions.

Posted: **Tue Nov 12, 2024 1:22 pm**

This thread STARTED as a "follow along" sort of teaching project (and it was not me that transformed it into a discussion).

My Sheba project is conceived on in the same way (and this weekend that thread will take up moreof my time than this one).

Your interpretation of the word 'Discussion' may be different to mine: certainly if you wish move this thread to the Education thread, but then move the Sheba thread there as well.

HOWEVER; one thing you need to consider is that we are attempting to attract new xTalk users, and completely new computer programmers to OXT (or, maybe that has slightly got lost sight of?), so, at present at least, I would have thought the distinction between 'discussion' and 'education' was rather thin.

ALSO, as this thread progresses, and as I "recycle" code from the examples I have already uploaded I shall be 'refining' them, explaining why, and asking a few questions re efficiency over ease-of-use, and so on.

and wait statements in animation are just a bad idea

could you also justify that statement?

Computers, in my experience, can often do things rather more quickly than the human brain can process . . .

How one ensures that an animation delivers frames at say, 25 per second, might prove difficult without wait statements.

Posted: **Tue Nov 12, 2024 2:22 pm**

richmond62 wrote: ↑Tue Nov 12, 2024 1:22 pm
and wait statements in animation are just a bad idea
could you also justify that statement?

This has been covered multiple times before, between xAction and yourself.

OpenXTalk Forums

Richmond's Yule Project

Richmond's Yule Project

Re: Richmond's Yule Project

Re: Richmond's Yule Project

Re: Richmond's Yule Project

Re: Richmond's Yule Project

Re: Richmond's Yule Project

Re: Richmond's Yule Project

Re: Richmond's Yule Project

Re: Richmond's Yule Project

Re: Richmond's Yule Project

Re: Richmond's Yule Project

Re: Richmond's Yule Project

Re: Richmond's Yule Project

Re: Richmond's Yule Project

Re: Richmond's Yule Project

Re: Richmond's Yule Project

Re: Richmond's Yule Project

Re: Richmond's Yule Project

Re: Richmond's Yule Project

Re: Richmond's Yule Project