Scorpion Engine

[Retro1234]

I know its crap but just for performance comparison that sample Backbone game the monkey with the gun I'd like to see this running under Scorpion

Thanks.

[DamienD]

Originally Posted by Gzegzolka

I remember there was a platform game made in backbone about Vampires, Curse of the Night. I am sure it deserves better engine.

That was nobody's game: Vampire: Curse of the night

[nobody]

Well yes but I lost all project files (actually lost everything about it) after a hard disk crash that had to format my pc. Maybe I could do another one from scratch if the engine can support it, like an enchanted version or something with extra levels etc. Backbone was too limited, I think I pushed it as far as it goes with that game, and also had to fit it to 1 disk.

[earok]

@Retro1234 The monkey game has various features that are either not currently supported by the converter (platforming, animated tiles) or are not yet implemented in Scorpion itself (background gradients, which I'm honestly not a fan of and i'd rather not implement at all, as well as ducking which I'll need to investigate implementing).

I can look at that, as well as a Chaos Guns conversion, when TOG1 is done.

@nobody If it comes to it, I'd be able to convert the levels, tilesets, sprites and sound effects without the source, but the logic would need to be built from scratch though.

[Retro1234]

Thanks dude, although its a rather terrible game it has 8 way scrolling and unlimited bullets? it would be very interesting to see it running with Hardware scrolling its the only Backbone game I can remember and iirc it was painfully slow.

[earok]

I've done a push to the git repo with some minor memory/disk optimisations.

The compiler now packs graphics so that each image and mask is packed only once (so, for example, bobs with identical masks only have one copy of the mask added to the project output), also it now uses Modpacker to clean each mod file in the project to save a few KB here and there (I've seen it strip 50KB out of some larger mod files).

[saimon69]

This is a question i had since a while, but do the sound routine in blitz - or a custom made one - support multiple songs in a mod file (via jumping at a specific position in the song)? Am asking because am helping others that use Blitz and having a similar feature will save some space

[earok]

Originally Posted by saimon69

This is a question i had since a while, but do the sound routine in blitz - or a custom made one - support multiple songs in a mod file (via jumping at a specific position in the song)? Am asking because am helping others that use Blitz and having a similar feature will save some space

In theory, that shouldn't be too hard. Can you give me a mod with multiple songs, as well as the start positions for each song?

[saimon69]

Originally Posted by earok

In theory, that shouldn't be too hard. Can you give me a mod with multiple songs, as well as the start positions for each song?

can send you via PM

[earok]

I've done an emergency check in. I had missed a bug that meant some of the blocks on the Alex Kidd demo were distorted (I had forgotten that not absolutely everything had stored the addresses of masks. Since the GFX packing is a little smarter, there's never more than one copy of any mask in memory. Some parts of the code had the assumption that the mask would always be directly after the image. Whoops).

Do feel free to test any checkins I've done, my GIT commit process also generates LHA's of all of the sample games.

I've also (thanks to JMD's assistance with a test song), added the ability to skip to any position in a song. Eg,

~ Music = Song //Load the song
~ MusicPos = 16 //Jump to $10
~ Wait = 50 //Wait 50 frames
~ MusicPos = 8 //Jump to $8

[earok]

I haven't posted for a little while, so here's a quick update.



The 'automated' side of the Backbone conversion for TOG is more or less complete, from here on out it'll all be manual tweaks, bug fixes and enhancements. I'll be posting the changes I make as mini tutorials.

I have been starting to think about another sample game to work on this weekend, and there are a couple of different options that are interesting me, otherwise I could look at another level of Alex Kidd or adding combat to the Zelda demo.

[breech]

Apart from the github blurb, are there any tutorials / documentation / vids available? If not please focus on that? Cheers

[Clydos]

NICE, earok, thanks for the update!

[Tigerskunk]

Very nice!

[earok]

Thanks guys.

Originally Posted by breech

Apart from the github blurb, are there any tutorials / documentation / vids available? If not please focus on that? Cheers

Well, that would be the logical thing to do..



The dilemma I have is documentation (though I am making progress in that regard) is time consuming (and I don't have a lot of that available), and with the engine evolving I need to write and rewrite documentation as things change and new features are added.


I'm not really set up for making videos, but - if someone wants me on their stream, I'm happy to do something similiar to what I did for Amiten with the Blitz Basic tutorials.



Hmm.. if I do a new sample game, I could maybe I could document the process as I go (here, or on a blog or something) to work as a tutorial.

[earok]

First of the posts about manual tweaks for TOG.

This is how it currently looks. Bear in mind that we're playing with the palette, and that we could possibly edit the visuals, so the look and feel definitely isn't final.



The first thing we need to fix is the large gap between the game and the UI. If we look at the PNG of the UI, we can see the issue straight away:



The panel has a large black space at the top, which we can simply crop out. But this introduces a new issue, in that we need to reposition the bar positions as well. We need to look at our project.txt



We've defined two bars, which are linked to the CurrentLives and CurrentEnergy variables. Note that Scorpion is able to render bars based on any variable in the game (so, for example, it'd be possible to render boss health as a bar), and it derives from source images rather than a single flat color (so it'd be possible to nicely decorate a bar, or give it horizontal or vertical gradients).

Since we've removed the top 23 lines from the PNG, we have to move the Y values from 28 to 5. Done.

[Tigerskunk]

Love reading this stuff...

[earok]

Originally Posted by Steril707

Love reading this stuff...

Great!

Well, it's time for a new mini tutorial.



Like many Zelda style games, Tales of Golurth has destroyable bushes. But due to the limitations of Backbone, there were some quirks with how they were implemented:

So far as I can tell, Backbone doesn't have the ability to implement 'destroyable' blocks (at least the kind that have hidden items inside - I'll talk a bit about that on the next tutorial). So here, the bushes were implemented as actors - essentially, enemies that don't move.

Also, they don't stop you or an enemy from simply walking through them, but they do incur a health penalty to discourage you from trying.

Having them as actors rather than blocks is also both CPU and Blitter intensive - the six bushes here incur a similar overhead to actually having another six enemies on screen, as they need to be redrawn every frame. So let's fix that, by changing the bush actor to a block.



In our project.txt, we can scrub most of the lines that defined the bush as an actor, and instead use three lines to define the bush as a block:

- Source: Simply the source image.
- Solid: Our block cannot be walked or shot through through.
- Divert_PlayerProjectileCollision: What happens when we shoot it.

In order to define how we handle the collision between a player's projectile and the bush, we need to add a few lines of code to our project.ink file.



The lines of our function:
- Set the block type to null (destroy the bush)
- Set the player projectile type to null (destroy the sword)
- Play the sword sound
- And finally, return control of the program to the game


Now that they're blocks instead of actors, they incur very little overhead - they're only redrawn when they're scrolled into view or overlapped by a bob, and they have no per-frame AI handling or collision checks. We could fill the whole level with them with pretty much no slow down.

[DamienD]

Heya earok,

Trying to think how to word this without sounding too harsh...

Regarding your Scorpion engine, it does look amazing

A one thing I don't really understand though; why are you focusing on being able to import Backbone games into it?

People should really be learning to use your new engine; having the ability to do the above will probably mean that existing Backbone authors will continue to create in that, and finally just import into your engine.

You also seem to be spending a lot of time / effort reworking viddi'd TOG. What's next; the conversion of TOG II?

Now that you've got the Backbone --> Scorpion import working to a decent degree; wouldn't it be better if viddi works out the subtle differences? This would also help him learn your engine for further games that he may have planned.

I don't know, we haven't had an update to Alarcity in well over a year now. Personally I, and am sure others feel the same, would much rather see this being worked on instead of revamping TOG games.

...but maybe it really is a gone project now; especially with Tsak working on Metro Siege?

[malko]

Originally Posted by earok

[...] Well, it's time for a new mini tutorial. [...]

Thanks mate !
I know the documentation is the weakest son of every family , so continue the tutorials as you are doing now .
Then it will be possible to merge everything in a file and call it "a documentation" .