[Why-Fi]

Hey guys! How has it been?

Another semester has come and gone, and I found myself some free time to work on my own projects and generally muck around and learn stuff that might help me in both my future career and improving myself as a person. Then, one boring day, I stumbled upon my MZX folder once again and thought I might do something (perhaps) useful for this community for once. I have some ideas for a couple games as well as utilities, and I thought starting a journal would be a good idea to both get your feedback on the subject and to keep track of what I'm doing and motivate myself to push forward and not get sidetracked by whatever and never finish anything MZX related as before.

So, let's get started.

Things I'm currently working on (in order of progress):

- SMZX Mode 2 PalChar Edit - Released and Updated!
- Roguelike cave generation and FOV engine - Demo released
- Pathfinding engine - Completely rebuilt from scratch and working!
- Sprite IDE (20%)
- Extendable/customizable particle engine (5%)

Details and screenshots will be added as progress is made. These may or may not be used for a future game I'm planning, along with some other stuff I'm planning on doing, if I have the time and skills for the job.

Of course, your feedback will be precious, so feel free to drop a comment whenever you feel I'm doing something wrong so I can improve it.

PS: Lachesis, sorry for leaving you hanging with those bug reports, I'll get right back to getting you the data you requested back then.

This post has been edited by Why-Fi: 03 April 2015 - 05:33 PM

[Lachesis]

Well, best of luck

[Graham]

Sounds interesting. I'm looking forward to seeing what you cook up.

[Val]

Aw yiss />

[Why-Fi]

Some progress has been made, so I'll report here with a brief description of what I've been working on.

Sprite IDE: 'Spritely'

Not too long ago, I happened upon the wiki page detailing the usage of Sprites with a pretty fleshed out tutorial. I was particularly intrigued by how there appears to be a feeling of reluctance towards using sprites, as noted by the author of said page. That inspired me to start developing Spritely, a GUI (as GUI as MZX gets, anyways) based editor for sprite design, featuring mouse + keyboard controls (hopefully, intuitive enough for the newcomer and speedy enough not to be a burden to the old timer), block/mass char editing (I know how you can do that with the built-in char editor, by holding shift when selecting characters, but I felt something more "on the spot", where you can see the entire sprite you're trying to edit on the screen and get a feel of how it'll look like as the final product), the "object and layer sprites" idea implemented into a design model and more features that might make the process of setting up sprites for a game more intuitive. Of course, the way I implement things might not be the most useful (if useful at all) or adequate for fellow MZXers, so feel free to suggest changes as I go along and implement features.

Sorry for not bringing something more fleshed out or comprehensive for today, but there's still quite some work ahead of me and I hope I can get your opinions as I go along. Hopefully what comes out of this will be of use to someone out there.



As you can see, I'm using an interface design everyone's familiar with, in adition to mouse and keyboard shortcuts.

I'll report in as I add more stuff to it.

[smilymzx]

I have a interest in making sprites, Nowadays and in the past it is not very easy to set up!

Having said that, The new and upcoming Sprite IDE looks promising, I hope it does my job well after it is done, It may become a very great utility!

[Why-Fi]

Fellow MZXers, I present to you my new:

'Breadth-First' Pathfinding Engine in MZX

After a mix of boredom/interface issues/going out of town during my last days of holidays while developing the Sprite IDE (don't worry, it's still being worked on), I got inspired to finish this one and I did so! Engine is fully functional, but I'll take some time to polish some rough edges (to make the environment itself more presentable to the community) and write some documentation. In the meantime, here are some pictures and a brief explanation:


Interface is pretty simple: you control your cursor with the mouse, pressing tab toggles between Marking mode (marks the target cell for the pathfinding robot/sprite to move to) and Building mode (allows you to place and destroy customblocks to create obstacles for your testing purposes).

The little guy on the screen is actually not the robot itself: it's a sprite controlled by it. You can select where you want to have it initially placed; its default location is the one shown on the screen (10,14).
Although not currently showing anything, the status bar at the bottom will show various types of data on the counters used by the pathfinding algorithm. Speaking of which, this engine is VERY counter heavy. Its usage of counters is partly related to the size of the board and the number of concurrent pathfinding robots; with large boards and an high number of robots it might well surpass the "theoretical" counter limit that MZX currently has. Basically, for every cell on the board there's always at least a counter, and it uses &robot_id& in its name so as to make all counters used "pseudo-local" (concurrent robots are only limited by that theoretical counter limit).


Another debug feature being shown: by pressing 'd', you can toggle this overlay that shows cells already run through by the algorithm (it does so in layers, the number on the cell is the layer). Slightly buggy at the moment, will get fixed soon. (the target area is also marked with an 'X', the cursor is over it at the moment).


The path has been determined, and the red Xs represent it.

Some more examples:


Coming soon, in a vault close to you!

[Old-Sckool]

I made my own path finding engine but instead of using counters I just used the color variable in customfloors to make it colorful.

Also, I think Werv's comment about people being reluctant to use sprites is outdated. The few people who still release mzx games these days all use sprites from what I know.

[Lachesis]

no True(n) and xx̊y did, anyway.. I never saw why anyone had issues with them to begin with <.<

[Wervyn]

Keep in mind that I wrote that tutorial in, I think, 2008. The technical information in the tutorial isn't particularly out of date, but the community context is. My point at the time was specifically that sprites weren't really that big a deal to use, and that more people should use them. Given how the community has developed in the past 6 years, I don't suppose we could strictly say that more PEOPLE use them now. But I'll settle for "a greater percentage of the active community" as a metric and call it a win.

"Lies, damn lies, and statistics."

[Why-Fi]

Well, it's been three months and still no more progress. "You lied to us", you might say. And honestly, the biggest lie here was to myself, claiming that the journal would help me keep track of my progress and not get sidetracked.

However, to be fair, university projects and other such troubles have been keeping me busy, while MZX requires some free time on my hands. Therefore, with the summer holidays coming up soon (though not for long), I'll dedicate myself to these (and other) projects again.

In the meantime, here's a quick little peek into another engine I started working on (a small endeavor, to be honest).

[Graham]

Don't be too hard on yourself. We have all been there and we all understand these things take time and you have a life beyond making games. Remember, it's for fun :-)

[Why-Fi]

After about 7 months of setting up this list of projects so I'd keep up my pace, I still had nothing palpable to show. The thing is, I'm always left with the impression that due to my skills not being up to snuff, there are always bugs in my engines and just overall bad performance, even on my fairly powerful PC. I have this bad habit for "set "commands" "(1000000)"" on everything, and it results in issues like with the pathfinding engine, being my most worked on engine until I got some severe lag issues, with my CPU spiking to 100% for a few times, and being unable to solve it while leaving the engine at a workable speed, I just kept it as it was, in hiatus, without a clue on what to do.

You might be asking yourselves, what is the purpose of these engines? While some are just intended to be used "as is" (Spritely, for instance), most of what I'm currently developing is due to my intentions to actually make a fully fledged game, a roguelike, more precisely, using these mechanics. I've grown more and more fascinated by roguelikes in recent times and given that it'd be a good motivation to do some MZX coding, why the heck not?

Today I can say that I set a small milestone towards that goal, having developed my FOV (Field-of-View) engine to a fully functioning (albeit slightly laggy, not noticeable in a roguelike context though) state, along with a cave generation algorithm based on a cellular automata method I found here and adapted for MZX. I'm pretty impressed with the results, in terms of generating interesting caves to explore. What I'm not impressed with though, is the performance. The algorithm takes a long time as it doesn't guarantee connectivity (there may be isolated cave segments, and it happened in the original version from Rogue Basin as well). Therefore, I used a pretty lazy method of preventing this: after generation, a slime is spawned in a random location in the cave and let to grow (who knew built-ins would be useful, huh?). Once all slimes die, a scanner goes and counts up all the remaining spaces, since those weren't connected to the cave the slime spawned in. If those are greater than 5% of the board size, the entire cave is regenerated from scratch, else, they are simply turned to walls like they never existed.

As you can see, it is far from perfect, but at least it's something I can show to the community and ask for your opinion on. Perhaps some of you more knowledgeable programmers might have some tips on how to solve my chronic dependence on increasing commands, mzx_speed and busyloops. Perhaps someone will find a use for this engine themselves.

Cheers, and good night.

EDIT: Derp, forgot the actual insctructions for the engine. Press P and wait for the cave to be generated. When it's done, the objective is to navigate from your spawn point (red stairs) to the green stairs located somewhere in the cave.

Attached File(s)

•  RogueCavesDemo.mzx (18.62K)
  Number of downloads: 91

This post has been edited by Why-Fi: 11 August 2014 - 07:34 PM

[asgromo]

:DDDD Flimsy Parkins and I did the cellular automata + slime trick for his own little maze generator some years back and it was basically the single funnest dumb thing I ever did in megazeux

[Why-Fi]

Ok, so given how I haven't made anything MZX-related in a while (save for screwing around with emscripten and not achieving anything) and I let this journal get buried, here's something to un-bury it.

One of my game plans for the future involved using SMZX, and I've been meaning to find a way to turn the cumbersome process of mapping the palette to the 4 colors of each char (in SMZX 2, I mean, SMZX 3 is straightforward) to make my job easier for later. The problem is, although there are some great tools such as Palmaster available, they seem to be restricted to editing the palette itself and don't really help you with mapping the colors to the characters you want to use, so that you are able to, in real time, select which combinations of colors you will be using and manage the entire palette efficiently. To that end, I scribbled together a palette + char editor that hopefully makes that task easier.

Note that this is not "production-ready". The interface is kinda unresponsive (something to do with the "event loop" and waits in the wrong places I assume) and for some odd reason, colors 2 and 3 (or 1 and 2 in terms of code) are swapped in the char edit box and the charset itself (as you can notice in the following screenshots. This may have something to do with one of the calculations for drawing the char pixels on the screen (my quartenary skills aren't very good) or something wrong I did with the SMZX 2 mapping system itself.

Anyways, if you guys show interest I'll look to fix these two bugs and submit it as an utility in the vault. Who knows who this tool might be useful to.

Attached File(s)

•  SMZX2PalEdit.zip (5.89K)
  Number of downloads: 72

[GetDizzy]

That's a neat combination I've found myself wanting before. Cool stuff.

[Graham]

Oh wow, this is something I might be able to really use! My game uses SMZX mode 2. I will download when I get home and check it out. Thanks

[Why-Fi]

Graham, on 17 March 2015 - 08:36 PM, said:

Oh wow, this is something I might be able to really use! My game uses SMZX mode 2. I will download when I get home and check it out. Thanks

I doubt it'd be very useful before I fix the inversion bug in colors 2/3. Since you're interested though, I'll look for a fix it as soon as possible.

[Lachesis]

looks neat! not sure i'd use it myself, though.

what I think would be really cool is an SMZX multi-char editor where you can give each char its own palette

[Why-Fi]

Lachesis, on 18 March 2015 - 06:36 PM, said:

looks neat! not sure i'd use it myself, though.

what I think would be really cool is an SMZX multi-char editor where you can give each char its own palette

I thought about that as well, I started with the easier and more essential part first though. But it's food for thought for a future improvement, of course.

[Dr Lancer-X]

btw, in all smzx modes, colours are as follows:

00 - 0
10 - 1
01 - 2
11 - 3

if you were expecting binary, that's probably where you went wrong. yeah, it's kind of annoying, but i guess that's how the display mode these modes are based on worked. i often solved this with a lookup table:

set "smzx0" 0
set "smzx1" 2
set "smzx2" 1
set "smzx3" 3

[Why-Fi]

Lancer-X, on 19 March 2015 - 12:43 AM, said:

btw, in all smzx modes, colours are as follows:

00 - 0
10 - 1
01 - 2
11 - 3

if you were expecting binary, that's probably where you went wrong. yeah, it's kind of annoying, but i guess that's how the display mode these modes are based on worked. i often solved this with a lookup table:

set "smzx0" 0
set "smzx1" 2
set "smzx2" 1
set "smzx3" 3

Ah, I basically just used the built-in counter help page for guidance and it doesn't state that for some reason. But it's definitely that. Odd notation, it's not even Gray code or anything.

[Dr Lancer-X]

not that odd, it's just bitwise little-endian.

and yeah, the mzx help file doesn't say this. moreover, it gives an example of calculating char edit values in smzx and that example is wrong.

and i've never reported this to terryn because i only just found out psx is the system with saga frontier 2

[Why-Fi]

Lancer-X, on 19 March 2015 - 01:05 AM, said:

not that odd, it's just bitwise little-endian.

and yeah, the mzx help file doesn't say this. moreover, it gives an example of calculating char edit values in smzx and that example is wrong.

and i've never reported this to terryn because i only just found out psx is the system with saga frontier 2

Exactly, that's the example I followed when working out the math for this.

[Terryn]

Noted. Apologies.

[Dr Lancer-X]

Terryn, on 19 March 2015 - 06:01 PM, said:

Noted. Apologies.

the thing about the help file is that it is something that is expected, so the most common feedback you will get is 'this is wrong' or 'this is unhelpful' or 'this is missing'.

so on behalf of everyone, thank you so very much for the help file and it's no big deal if there's occasional errors. i lost a lot more time to wikipedia screwing up the damn alpha compositing formula anyway.

[Why-Fi]

Terryn, on 19 March 2015 - 08:01 AM, said:

Noted. Apologies.

There's no need for apologies. Overall, the help file is very concise and does its job quite well, this was frankly the first mistake I found in it. These things happen, occasionally. Additionally, the wiki's getting quite complete and complements the help file fairly well.


UPDATE: Bugs fixed, editor polished, and it's released! Waiting vault approval. You can grab it here in the meantime.

UPDATE EDIT: Found a serious bug with a zapped label not being restored and the saving/loading dialogues. Fixed.

Attached File(s)

•  SMZX2PalCharEdit.zip (8.09K)
  Number of downloads: 82

This post has been edited by Why-Fi: 20 March 2015 - 09:10 AM

[Graham]

There was an unintended consequence of loading my own char set into the editor, since the set you are using for the UI is the same and unfortunately isn't protected or anything />

yeah, now it looks kind of ugly and hard to use. bummer.

on the upside though, the interface is really nicely designed and well thought out. It may have it's uses as a palette editor, I'm just not sure how I could incorporate an existing character set into it though. Trying to use it with screwed up characters like that is really rough. It could be perfect for partial char sets though. can you load a char set offset currently, or just at 0?

Also, I've kind of already created a fix for my game. I wrote my own palette editor into my game so I can edit the palette during testing, this allows me to make certain I'm not creating conflicts when I change a color. Tricky things those SMZX palettes. Thanks for making this thing, it's a cool idea!

This post has been edited by Graham: 22 March 2015 - 04:45 AM

[Lachesis]

Graham, on 21 March 2015 - 10:43 PM, said:

Also, I've kind of already created a fix for my game. I wrote my own palette editor into my game so I can edit the palette during testing, this allows me to make certain I'm not creating conflicts when I change a color. Tricky things those SMZX palettes. Thanks for making this thing, it's a cool idea!

that's actually pretty brilliant. i should keep that in mind for the future...

[Why-Fi]

Graham, on 22 March 2015 - 04:43 AM, said:

There was an unintended consequence of loading my own char set into the editor, since the set you are using for the UI is the same and unfortunately isn't protected or anything />/>
screen1.png
yeah, now it looks kind of ugly and hard to use. bummer.

on the upside though, the interface is really nicely designed and well thought out. It may have it's uses as a palette editor, I'm just not sure how I could incorporate an existing character set into it though. Trying to use it with screwed up characters like that is really rough. It could be perfect for partial char sets though. can you load a char set offset currently, or just at 0?

Also, I've kind of already created a fix for my game. I wrote my own palette editor into my game so I can edit the palette during testing, this allows me to make certain I'm not creating conflicts when I change a color. Tricky things those SMZX palettes. Thanks for making this thing, it's a cool idea!

Yeah, that's an issue I thought about but sadly I couldn't think of an easy way to fix it for now. The partial charset idea is interesting though, I'll keep that in mind for a future version, changing it so the interface characters are "protected" and you can't change them and modifying the saving and loading as partial charset operations. The way I'm planning to use it for my game would work that way, I just need the editor so I can design characters with specific colors and make sure I don't screw up the palette or something with that in mind.

I'm also looking forward to implementing Lachesis' suggestion of multi-char editing, with each char having its own 4 possible colors, which would be useful for creating SMZX sprites, such as your player character in Servo.