Scorpion Engine

[malko]

Originally Posted by gimbal

I don't really. A lot of C# (or Java, or whatever platform is your favorite) applications actually will stay on exactly one machine and then you just want to be able to rely on system defaults.

I second earok. The number formatting should not rely on system default but on an internal format whatever the locale 'display' for the user is.

@earok : Scorpion is amazing'ier' as time goes

[domkid]

@ Earok, thanks for the video, great idea to add a feature for a CD32 iso, we didn't know how to do it.

[earok]

cheers guys

[ Show youtube player ]

Posted today's stream to YouTube. Went over and closed a bunch of resolved issues in the Git page, fixed a lot of bugs with the Pitfall sample game, and previewed the (very very early work-in-progress) port of Gunsmoke to Scorpion.

[Mixel]

That was a great stream! (thanks for archiving them)

One thing I noticed while I was doing my session, and I noticed it before too with my zombies, but wasn't really sure what I was seeing.. I don't think this is necessarily a bug, or even bad, but it might be?

If a platform actor is set to move towards player on a timer, that works great but if it's running that command when you're jumping above the enemy it stops in it's tracks, generally continuing to do the walk animation (because most enemies don;t have a looking up animation, though.. hell maybe i should make one for the zombies as that might be funny? haha) Is that intended behaviour? I can stop it by putting an is player onplatform check first... Just seemed odd?

ed: actually thinking about it the same applies if you're on a platform above/below the zombie.. I'll have to do an Actor/Player Y comparison to stop it happening.

[earok]

@mixel my suggestion would simply be to do something like

if actor_x < player_x
actor move right
else
actor move left
endif

The move towards player does take into account all eight directions by design, it's agnostic to the type of actor actually doing the movement (and it could be useful as is for enemies that jump at the player).

---

First update of 2022.2 has been pushed to experimental with a new dialogue demo and improved string management features.

1. You can print variables in dialogue, eg "You have $2:coins coins" would print to "You have 99 coins" if the variable value for coins was 99.

2. The quit command allows printing a message, which also allows for custom variables as above.

3. The AmigaDOS execute command also allows for custom variables. The dialogue sample stores the result of the last dice roll in an environment variable upon quit, which you can see on the command line by typing "echo $dice"

[acidbottle]

Just watched the twitch stream from the other day, is really great stuff, particularly impressed with the train trick on gunsmoke, awesome job!

This question am sure has been asked many times but how big can a map be in tiles again? Have a level that is a whopping 8160 x 850, it does not run unless I half this down, as a test. A few levels are massive, is it possible to override the limits even if left with consequences?

edit: text string variables have been added? <blink> NICE dude!

[earok]

cheers @acidbottle

8160 should fit just within the limits, the limit is currently 512 tiles on either axis and Scorpion reserves a one tile boundary around that on all sides, 8160 = 510 tiles so it should be fine. More than that, it should print an error saying that the maximum is 512 tiles if it exceeds that. Is it not compiling or it not running?

[acidbottle]

It compiles no issue but when the level is due to load it hangs on a black screen, it could be a weird tiled bug and not an SE issue to be fair. I dialed the map down to 4000 x 430 (essentially halving it) and it displays no issue.

While your here (UK mornings seem a great time to catch folk) ....

Have 2 very minor issues, 1 in relation to Z order, I have set fruit to be a higher number (at present 10) and my actor is on 0 .. yet the fruit is still behind. I reverse these properties and there is no change. I have no major specific reason to change Z order but noticed the fairy, which uses the old codeblock offset trick, not parent actor, glitches a little when i pickup a fruit. This started happening in the past few builds if that helps.

Thanks for your assistance as always

[earok]

I can't explain that, I'm assuming that you're not using sprites at all? (if you are, sprites will always be above bobs regardless of z-order)

If you can give me a copy of your game, I can take a look sometime

[acidbottle]

No, have about 4 sprites but none related to the actors involved.

Will send a copy of the game over hopefully tonight, cheers

[Mixel]

Originally Posted by earok

@mixel my suggestion would simply be to do something like

if actor_x < player_x
actor move right
else
actor move left
endif

The move towards player does take into account all eight directions by design, it's agnostic to the type of actor actually doing the movement (and it could be useful as is for enemies that jump at the player).

That absolutely makes sense, TY.. What's odd is I'm pretty sure I was having the zombies standing around issue before moveatplayer even existed so I was clearly doing something very silly!

Acidbottle: I missed text string variables too?

[acidbottle]

Originally Posted by Mixel

Acidbottle: I missed text string variables too?

Not sure I read that correctly on second blink! But seems you can add string variables to dialogue which is still very neat. Had visions of adding a hi-score table prematurely Think I need to download latest build and see this new function properly haha!

[Mixel]

Originally Posted by acidbottle

Not sure I read that correctly on second blink! But seems you can add string variables to dialogue which is still very neat. Had visions of adding a hi-score table prematurely Think I need to download latest build and see this new function properly haha!

LOL that was just me failing to read the bit of the post that wasn't directly aimed at me because I'm an idiot who needs more caffiene hahaha.

Oh man that's a huge, HUGE deal and perfect timing at this end.. I'm starting proper work on my shops and password screen soon and strings in dialogue boxes could make that work so much easier.

[griffon]

Woohoo string support update! I definitely am gonna use that ASAP

EDIT: looks like it's numeric variables only, and not strings. Oh well. Maybe a CHR$(numeric variable) addition would fill the gap until proper string support is added?

Thanks Earok!


And to all people that, like me, had problems with actor and paths and have not their system set to english: the local patch will fix that!


Back to the programming cave now

P.S. the dialog to select commands and variables is shifted to much to the right on my screen and I can only see part of them unless I use the search function.

[saimon69]

Am the one with the difficult questions all the time, however since am a curious person and like to push boundaries i wonder: would switch from a Blitz Basic compiled output to a C compiled output increase performance? And how tough would be to do that transition? Was thinking the same for the RedPill Engine

[earok]

I honestly don't know. While C compilers are extremely well optimized, Blitz is designed for 68K specifically (and so, for example, parameters on function calls only use data registers rather than the stack), and in any case more and more of the engine is gradually being converted to ASM. C would be pretty useful for cross platform support, but I'm not sure when I'll get around to a C version and if it would completely supplant the Blitz version.

[saimon69]

Originally Posted by earok

I honestly don't know. While C compilers are extremely well optimized, Blitz is designed for 68K specifically (and so, for example, parameters on function calls only use data registers rather than the stack), and in any case more and more of the engine is gradually being converted to ASM. C would be pretty useful for cross platform support, but I'm not sure when I'll get around to a C version and if it would completely supplant the Blitz version.

Assembly is even better - if for amiga only, but i did not dared to ask -_-

[earok]

Minor check in to experimental:

- Fixed a bug where occasionally a non-player actor can temporarily become the player (and so player_x etc was pointing to the wrong actor)

- Added some better handling for broken levels (for example, if your level uses a tile that's outside the range of a tileset, it will tell you where to look to solve it)

- Rewrote a fair bit of the code generation (so more of the codeblock processing is ASM and less of it is blitz). Not quite sure if this causes any bugs but do let me know if anything suddenly isn't working!

Originally Posted by saimon69

Assembly is even better - if for amiga only, but i did not dared to ask -_-

No worries! Scorpion's optimization is ongoing but I can't say for sure whether a fully ASM engine or a C/ASM engine would ever be a possibility (the latter is more likely mainly because cross platform support is planned)

[griffon]

I'm not sure if it's a bug introduced with latest experimental, since it's something I just tried out, but I have abused the parallax system to show more colors onscreen, without using an actual parallax (dividing the screen in vertical stripes, and using the three colors reserved for sprite parallax on the background, and so on. While keeping all the sprites as transparent color. It's a waste of sprite resources but oh well).
It works, but whenever I use two panels on screen (the lower and the overlap one, respectively), the copper is either paused or disable while the overlap panel is shown, effectively killing the extra colors until it's closed. Is that by design?

[earok]

Not by design, maybe try increasing the panel_gap? I'm assuming that there's just not enough copper time to reinitialise the copperlist in the time between the top panel and gameplay view.