Prince Of Persia FX- is it doable?

Help & Information
#3

@Pharap Thanks for the reply.

To be honest, I’ve never seen an example that has convinced me this ‘technique’ is viable or even actually works. To me it never looks grey, it always just looks like two frames flashing between each other.

I do find it looks grey to me on ‘Ard Driving’. But, it is a bit distracting. I may still try it for the character sprites if I don’t like the monochrome look once I see it in motion.

Honestly, trying to compare the size of machine code implementations between architectures can be a bit like comparing apples (if you’ll pardon the pun) to oranges

Good point. And pun :slight_smile:

And don’t forget that colour images use a lot more bytes than monochrome (1 bit per pixel) images.

Right. I had initially thought that they were monochrome, but I was looking at monochrome image sprites that someone had used for a Commodore 64 remake. So yes, they will be pretty small.

However, there’s an Arduboy port of Karateka and I get the impression they have a similar set up (at the very least in terms of side-scrolling rotoscoped graphics - I’m not sure if Karateka’s graphics were rotoscoped like Prince of Persia’s were, but they look similar enough).

Indeed, I actually used that port as a rough shell for mine.

It’s not the immutable data you have to worry about, it’s the mutable data, because you only get just over 1KB of RAM to work with (or slightly more if you’re willing to attempt some crazy custom screen rendering).

Yeah, that’s tight. I’ve never worked in such a constrained fashion. I don’t mind digging in - I want to learn this stuff, and I have a development background, but it’ll likely be something I just need to get on with and see how it goes. I just don’t want to hit a wall that I don’t see due to my lack of experience here.

The logic in Karateka is a good bit simpler, but it is in the same vein. I should have a close look at how much breathing room was there.

The VM is an interesting idea, but I’ll have to think about how much I could really offload. Probably not enough to make it worth it, but it’s something for me to consider at least.

#4

If you use code from Karateka in the final version, don’t forget to adhere to the licence.

Bear in mind that it’s actually storing everything in progmem because it predates the FX chip.

Again, it really depends what kind of scripts you’re thinking about offloading.

If you’re going for high quality animations then I can imagine making the VM oriented around animation might pay off. It doesn’t need to be anything too fancy, just enough to do some basic arithmetic, move some data around in a designated scratch space, and alter some struct fields on relevant objects (i.e. a means to interact with the ‘outside world’ of your game engine).

Since Prince of Persia was originally for the Apple II, I can’t not mention the VM that Steve Wozniak created for the Apple II:

A mere 28 functions (31 total with 3 unassigned), and the engine apparently taking up only 300 bytes of memory (which I presume includes the 32 bytes for the ‘registers’). It probably wouldn’t help you, but I mention it just because it’s a small piece of notable (and relatively unknown) history.

#5

Thanks. Appreciate the info. I’ll definitely honour the Karateka port license. I may not end up using the code, but I’ll be mindful of it.

1 Like
#6

The Apple II graphics were monochrome however they used a trick to make colour.

Rendering images directly from the FX chip is not only easy, its really quick too. You do not have to worry about storing them in progmem. POP is not a fast game so you should have no worries.

You could even have the level graphics stored in a single image that you scroll left and right allowing you to have larger graphics.I used a large world graphic here.

You would need to have a ‘map’ of the objects and their coordinates in order to use a graphic of a map like this but it would be doable.

I am hoping someone will use my ArduboyTonesFX or ArduboyPlaytuneFX libraries for something good.

When I was creating Karateka I obviously had no FX. The performance of the game suffered as I had to resort to compressed graphics to get it to fit. I also sliced the people up into heads, torsos and legs so that I could construct a person out of parts to save memory. All this rendering of masked images also takes its toll as the old drawCompressed() functions resulted in two calls - black out the mask and then draw on top. The FX has more features for masking and you have space to keep complete images of people therefore avoiding the multiple rendering passes.

If I did it again, I would simply create the cut scenes as a flipboard of images (shown one after the other). It is inefficient storage-wise but who cares when you have an FX?

2 Likes
#7

Thanks for chiming in.

This is great to know. I assumed I’d have to be swapping them in and out of progmem. Very nice :slight_smile:

I’ll do my best. Can the music be run without loading into progmem too? I’ve read a little about the difference between these 2 libs. Is this a fair high-level breakdown:

ArduboyTonesFX is more performant/smaller size, and doesn’t have a negative effect on LED
ArduboyPlaytune allows 2 channels simultateously?

I noticed you’d sliced all the components up. Good to know I won’t have to :relieved: Looks like a LOT of work.

Interesting idea on the cutscenes as well. So simple - like a short movie!

Re: a full level map image – that could really simplify things as well! I’ve though about showing less at a time and using larger character sprites. It could certainly work, but there’s something about seeing each “room” in it’s entirety at once. Though… you never really need to change rows (i.e top, middle, bottom sections in a single room) quickly, so perhaps I could show the full active row, and half a row above and below.

Appreciate the ideas. I’m thinking I’ll likely go ahead with this project.

It’s one of my favourite all-time games. I played it as a kid on a Tandy and fell in love with it immediately. It’s a very satisfying game to play right through.

And if this goes well, maybe I could tackle Blackthorne next, as it’s kind of similar :slight_smile:

#8

Yep … they read directly from the FX chip. I must warn you though, I haven’t done any performance testing with them and a full graphics payload :slight_smile: As I said though, access to the FX chip seems to be really quick so I do not anticipate problems.

Correct. Even with the little piezo-electric speaker it can make a huge difference. Load up Trials of Astarok and you can hear the better sounds ArduboyPlaytune can make.

Nice and simple!

I wonder if you could have a map in the corner that shows a 1:4 scale that you can toggle using the ‘C’ button. Oh wait, that’s the problem with the Arduboy, not enough buttons!

But you do need to know if you can jump down. Is that a safe landing or a pit?

I grew up on Karateka and POP. I love them!

#9

Just thought of something … maybe you could have 4 or so images of the level or room you are about to enter at different scales. As you enter the room it zooms from a small image to full size so that you can see the room in its entirety before you play it.

#10

I’m thinking I could just have the camera pan up or down if I hold the A button (the careful step button) while pressing up or down. The only action it would coincide with would be when you’re lowering down a ledge, in which case you’d want it to pan down anyways.

I looked at the NES controls, since it only uses 2 buttons, and it looks like this would work.

Also, I found a video of a widescreen mod (with scroll) someone made of the MS-DOS version, and it’s a pretty nice effect - really looks like it improves the ‘flow’ of the game:

1 Like
#11

Oh that’s nice.

I remember that level completely!

1 Like
#12

I just did. Sounds great :). Now, does it only affect the LED while music is playing?
On a side note, that game is great. I had it loaded onto the flash, hadn’t tried it yet. Very addictive.

1 Like
#13

A very interesting article. The explicit mention of NTSC makes me wonder if the trick only works for NTSC and not for PAL or SECAM.

I was investigating Cabi last week (for hopefully obvious reasons) and wondered why it was producing a mask since the drawing function didn’t have a ‘mask’ parameter. This explains that.

This is a good idea and I’m slightly annoyed that I didn’t think of it.
Evidently I’ve spent too much time working with tile-based games.

Just to point it out, this isn’t possible for the same reason swapping code out isn’t possible. As I mentioned briefly before, progmem can only be written to when the CPU is in bootloader mode. Outside of that it’s all write protected.

The FX chip itself, on the other hand, is not write protected, so you can write to it from within a game. However, it’s flash memory so there are some limitations on how you can write.

During writing you can only set 1 bits to 0, if you need a bit to go back to being 1 you have to erase a whole ‘page’ of data, which in turn means you need to store anything you’d want to keep in RAM. (Fortunately you can use the Arduboy2 framebuffer for that, assuming you haven’t begun drawing yet.)

1 Like
#14

I probably won’t be able to start programming this for a while. I have a couple of projects ahead of it (main one being preparing an Arduboy-themed STEM program at my son’s school). I have a 1 month work sabbatical I’m entitled to take at any time, which I’ll probably use for this project. But it’ll probably be in the summer that I end up taking it.

#15

To clarify, I meant drawing to the frame buffer during the game loop, not “assuming you haven’t begun drawing images for your game yet”, but good to know anyway.

Even if you haven’t started your project yet, you’re free to ask as many questions as you like and/or ask for whatever help you need.

#16

Thanks for the clarification.

I’ll likely work in little spurts until I have time to fully dive in. I’ll focus on generating the level maps to start with.

I’m sure I’ll be asking plenty along the way, and appreciate the advice. :+1:

1 Like
#17

Would you please share these materials (Arduboy-themed STEM program) here?
Many of us will be very interested

#18

Absolutely, that’s my plan. I have a bit more prep work to do, but I plan to share everything I have - parts lists, lesson outlines (probably pretty lean), brochure, CAD models for the cases, fritzing diagrams, etc. I’ve also taken a lot of time putting together a flash cart, putting the little fixes in as I go to get the games all working correctly with the SH1106 displays I’m using, so I’ll share that as well once it’s done.

It’ll be a mini-breadboard build, similar to Mr. Blinky’s breadboy project, but half the size, using only 2 mini breadboards per unit. Here’s a quick preview from some early CAD renders (it’s changed a bit, but this is the idea)

Image 2022-03-13 at 3.17 PM
Image 2022-03-13 at 3.17 PM411×565 62.7 KB

Image 2022-03-16 at 12.50 AM
Image 2022-03-16 at 12.50 AM698×736 97.8 KB

I’ll start up a new thread once I have it all together and ready to go.

4 Likes
#19

Nice design. Curious about the breadboards connections. Do the display pins connect to the proper Pro Micro pins on that row or are you gonna cut the breadboard contacts on the top row?

Love the case looks almost like it was designed by Nintendo.

As for PoP I think it’s doable. All graphics and data can be stored on the FX chip and a small VM can do animations/cutscenes (I’ve been thinking on addin something like a simple VM to FX library that renders animations from a data stream).

What makes PoP so cool is it’s animations (and we need a pixel artist for them). To make it look good on Arduboy the character needs to be relatively large to make it work. Belows’s a mockup I made a while ago with 16 pixel high sprite. 20 pixels would be better but then some vertical scrolling must be introduced to keep the right ratio.

The extra black area at the right (or left) can be easily filled with part of the adjacent screen when a level is stored as a tilemap.

afbeelding

If you’re wondering about the speed of drawing graphics from FX chip. Check out my balls demo which draws 55 masked ball sprites on a tiled background made up of 16x16 pixel tiles all drawn from FX chip.

#20

Thanks. I thought initially about cutting the breadboard contacts, but it seems like too big of a hassle. Have you done it? Is it not bad. I’m planning on soldering up some basic connectors with some wire leads ahead of time to the displays instead, so the students can still just plug ‘n’ play. It’ll just be quicker for me, plus, the screen will be held in place by the case design, floating above everything else.

I intentionally copied the Game Boy Color style for this. The buttons are GBC replacement buttons from Aliexpress, too. Thought about 3d printing them, but these are really nice. Glad I ordered them instead.

I’ll probably need this. You’ll be my hero if you make it for me (like you have for so many other things) :laughing:

Re: the aspect ratios, yeah it’s a challenge, and a balance. I like the idea of having all 3 levels at once, but I also really like the extra details afforded by going full-width, and only 2 courses high, which fits the AB display almost perfectly. Note that you only have an 8-tile width on your mock - the original is 10 tiles wide, but it’s been done with 8 for a number of systems due to varying screen ratios. I’ll go with the 10.

I was actually considering doing both – by default, having it 2 courses high, always showing the full level below where applicable, which is more important for a gameplay perspective, but also having a less detailed, scaled down full view like you’re showing, as a pause menu (likely by pressing slow step and up at the same time. I would use the side space for menu options like exit, load, save, and show the level info and time left.

I could have the game playable in both ratios, or just use the full-room display for quick reference.

Regarding animations, it’s possible to get the a number of different sprite sheets from different versions. I’ve been playing around with dithering settings while scaling down, and some of them are working pretty well, likely only needing minor clean up. I’ll try that route first, likely with Imagemagick, and see how far I can get.

For the level tiles, I’ve tried it a little, with less success (especially for the 3-level display, where you just can’t make out the spike holes and pressure pads), and have had better luck with drawing them by hand, similar to what you’ve done there. My hope was initially to leverage one of the many ‘PoP level editors’ out there, and leverage their already-perfectly-created maps, but that would involve adopting the original versions tile layout, which is a little confusing (though I get it) and would probably end up being more work than just working in 3 rows of floor-to-ceiling rectangular blocks.

#21

Here’s a quick screen I did showing what the first room would look like showing only 2 levels, but full width. The room details look pretty good. Each ‘block’ is 12 x 28 px. I also added an elevated ‘pad’ to make sure I could easily tell it was a foot switch. I really don’t want the player to have to focus in to be able to see these, or spikes, etc.

The kid still doesn’t have a lot of details, but every pixel helps here, and I do think it’s OK. For this one, I rescaled and dithered a sprite from the old Mackintosh version (with the vest, turban, and puffy pants), as I feel those ones retain their details a bit better when shrinking (plus I like the look of them at full scale). After scaling, and dithering, it just took a couple of minutes of manually adjusting a few pixels to clean up a couple proportions. I think this could be a viable workflow for converting the character sprites.

I think with a little more attention to the scaling process and dithering algorithm, I could probably get through the entire character sets in a day or two.

Room 1

2 Likes
#22

This is a really quick stab at the running animation sprite. I didn’t give any special attention to it – just scaled and dithered the entire sprite sheet at once and threw together the running ones in a quick loop.

The final should look at least this good, with a little attention given to optimizing the sprites.

dither_it_MacRunningSprites (2) (1)

1 Like