Jump to content
rensoup

Unicorns season: Prince of Persia for the A8!

Recommended Posts

1 hour ago, Jacques said:

Fantastic news, I'm sooooooo happy to hear we're going to have PoP on 8-bit Atari in the end.

Just a question regarding coulour-scheme, will the first levels stay green(?) or maybe there would be chance to make them Amiga/Atari ST/PC/CPC-like - in the PoP-classic shades of blue?

of course 😁

 

We know the patient has a pulse because the torches are burning but how much of a pulse? I intercepted the player's position and added a rectangular PMG to find out!

 

Also added status line and text line and because it's 2019 the font is proportional, that alone makes it well worth the 30 years wait 😀

 

popplay1_.avi.gif.dd21f171ccfba5cc0b95a0443e4dc2c4.gif

 

(hope it's ok to upload 1MB animated gifs)

  • Like 16

Share this post


Link to post
Share on other sites

I love the buzz on this, good luck with the game rensoup and lets see all the dev's chip in as seen so far. 

 

POP on the Atari, another milestone!

  • Like 2

Share this post


Link to post
Share on other sites
41 minutes ago, rensoup said:

of course 😁

 

We know the patient has a pulse because the torches are burning but how much of a pulse? I intercepted the player's position and added a rectangular PMG to find out!

 

Also added status line and text line and because it's 2019 the font is proportional, that alone makes it well worth the 30 years wait 😀

 

popplay1_.avi.gif.dd21f171ccfba5cc0b95a0443e4dc2c4.gif

 

(hope it's ok to upload 1MB animated gifs)

How will you get Prince and enemys?

On ours team we have on  all levels white one of the PFs then from Ste86 frames I could get things using Prior like:

-> Prince: PF0_white for clothes, and sword then PM0/PM1 for is skin that Oring PF0 gives his light brown/yellow hair;

-> Enemy: PF0_white for the tunic and sword, PM0 and PM1 for the trousers and shoes while Oring PF2 will get its skin;

If in levels you have carefully choose of the PF2 colour oring it can gives always a brown colour F for the skin the enemy's.

Share this post


Link to post
Share on other sites

I want it all, I want it all, I want it all, and I want it now.

 

👍

  • Like 3
  • Haha 1

Share this post


Link to post
Share on other sites
1 hour ago, rensoup said:

-What's in the 512KB ? premirrored sprites of course but that's about 40KB or something ? sound samples ?

 

-Why did you use a mask buffer for masking the sprites, instead of masking the sprites directly with the object in front of it ?

I'm currently using software sprites only but will eventually add skin color with hardware sprites which will require masking them and I figured I could just take the front objects that the game flags for redrawing and apply them as masks (the generic pillar for instance is a plain rectangle drawn with STA mode so that would be fast, the gates would require proper masking of course)

 

 

Well, once I decided to go via the cartridge route, I didn't have to optimize for memory size anymore, so I optimized for speed instead. So e.g. the level blueprint data is no longer compressed and aligned to bank boundaries, to allow it to be accessed directly (about 40K).

Also all the background drawing (and clearing) code is unrolled (about 64K).

The title screen picture and the title cards are stored as bitmaps (about 72K).

The music code and data is about 8K (data streams converted from MIDI data, no patterns or other size optimizations).

The cutscene (princess room) background bitmap is another 10K.

The animation frames for the kid are aligned to fit into hardware sprites, so they take up about 40K per direction.

The frames for guard, fat guard, skeleton and vizier are about 8K each, for each direction.

Dungeon and Palace backgrounds are about 16K each.

The main part of the code is 24K compressed, and some code (about 8K) is kept uncompressed in ROM, to execute it directly (such as the AI and sword fighting logic).

There's also a little intro with a manual reader (about 24K).

The sound effects are in their own 8K bank.

The rest is miscellaneous stuff and alignment overhead, and some free space to save the game state to the flash.

 

The characters are drawn using hardware sprites, and need to be re-masked whenever they move, so it seemed easier to build up the whole mask first as part of the initial screen draw, instead of having to figure out the part of the screen that needs to be used for masking by walking the image lists again. I'm sure the other way round might have worked as well, but it's essentially another speed vs. memory trade-off.

 

  • Like 4
  • Thanks 1

Share this post


Link to post
Share on other sites

I would go for the direction of bank switched cartridge and keep it under 48k ram (no OS swapping), so it can be ported to the ATARI 5200 later if needed.

 

  • Like 2

Share this post


Link to post
Share on other sites
5 hours ago, rensoup said:

I would probably have to store some game code into ROM which could be a problem as it uses selfmod code (sparingly though)

Indeed, that isn't a problem though, hopefully the Beeb assembler you are using can compile to an address but run at another?
 

When I do A8->5200 ports or C64->A8 then I come across this and both the CC65 suite (by which I mean the CA65 assembler and LD65 linker) or MADS let you specify different LOAD and RUN addresses. At load time you then relocate from ROM to RAM and anything using it knows correctly where to look :)

Share this post


Link to post
Share on other sites
4 hours ago, mrsid said:

The music code and data is about 8K (data streams converted from MIDI data, no patterns or other size optimizations).

 

Well, now that the beans are spilled, I can tell I was also approached for the music, looked into it and finally declined, mainly because of time issues. But in the end, my idea was to also convert the MIDI, by means of sdlpop/popmidi and have it output SAP-R at 50 fps. That way, it is way easier to sync cutscenes at the same points as the MS-DOS version.

 

Here's popmidi-1.4

 

https://forum.princed.org/download/file.php?id=1678&sid=5f2eaf2f11cff7a3d6f56bf29de0c0c5

 

This version outputs lines of text with all the events and plays through SDL audio and OPL3 emulation. This is what I planned to use as a basis for converting to Pokey and eventually as a generic MIDI to SAP-R Pokey, with mappings of each MIDI instrument to a Pokey instrument and a priority scheduler if more than 3 or 4 instruments play at the same time. A lot of the PoP songs "overdub" several melody and bass lines, but that's not necessary for Pokey. These overdub channels can be muted all together.

Edited by ivop
popmidi link etc....
  • Like 2

Share this post


Link to post
Share on other sites
8 hours ago, ilmenit said:

Looking at the discussion around Stunt Car Racer and xbios I hope the angry mob will understand how much time consuming it is to support all the "out of default" hardware or OS implants and modifications. As programmers we have limited time and do retro as a hobby, not asking money for our productions. Mob probably have no clue how much energy it takes to finish game and release. It's easy to get burn-out and leave project on 80% as a "tech demo". When I released His Dark Majesty years back I also got a lot of negative discouraging feedback "why you don't support QMEG, why don't it work on XYZ or ABC" and "WHEN ARE YOU GOING TO FIX THIS! IT'S NOT WORKING ON MY SUPERB ATARI HARDWARE FROM 21st CENTURY!".

I'm crossing my fingers for success of this project and hope that toxic people will stay away from it.

The backlash with XBIOS in general is saddening to see. Nobody needs negativity. Barbarians multiload makes use of it too. Reading the angry response Fandal got with use its use in Stunt Car Racer after his hard work was a off-putting to continue working on my own projects.

  • Like 3

Share this post


Link to post
Share on other sites

Do your job and don't let those trolls get you down. I wouldn't do any work to do them well.

  • Like 3

Share this post


Link to post
Share on other sites
7 hours ago, José Pereira said:

How will you get Prince and enemys?

On ours team we have on  all levels white one of the PFs then from Ste86 frames I could get things using Prior like:

-> Prince: PF0_white for clothes, and sword then PM0/PM1 for is skin that Oring PF0 gives his light brown/yellow hair;

-> Enemy: PF0_white for the tunic and sword, PM0 and PM1 for the trousers and shoes while Oring PF2 will get its skin;

If in levels you have carefully choose of the PF2 colour oring it can gives always a brown colour F for the skin the enemy's.

I don't think I'm going to use priority 0, not sure yet, I don't have all the art.

 

The plan is to use PM0-1 for player skin, PM2-3 for enemy skin, it's a little bit hazy. It's one of the big jobs left.

Share this post


Link to post
Share on other sites

 

7 hours ago, mrsid said:

The main part of the code is 24K compressed, and some code (about 8K) is kept uncompressed in ROM, to execute it directly (such as the AI and sword fighting logic).

So how often are you decompressing code ? i did some tests with a heatmap and I thought most of the code was accessed pretty much all the time (except the screen building perhaps)

 

Thanks for all the info, it had been bugging me for a while 😀

 

Share this post


Link to post
Share on other sites
4 hours ago, Wrathchild said:

Indeed, that isn't a problem though, hopefully the Beeb assembler you are using can compile to an address but run at another?
 

When I do A8->5200 ports or C64->A8 then I come across this and both the CC65 suite (by which I mean the CA65 assembler and LD65 linker) or MADS let you specify different LOAD and RUN addresses. At load time you then relocate from ROM to RAM and anything using it knows correctly where to look :)

Yes Beebasm is actually pretty nice for creating memory banks of code and data.

 

I actually figured the code would be run directly in ROM but with 16KB banks it would be a problem since the codebase is a lot bigger. There was a jump table for the game code for jumping across banks but I ripped it out to save memory 😶

 

7 hours ago, ndary said:

I would go for the direction of bank switched cartridge and keep it under 48k ram (no OS swapping), so it can be ported to the ATARI 5200 later if needed.

48KB would probably be tricky and if the 16KB window is inside those 48KB, it may need a miracle.

Share this post


Link to post
Share on other sites
3 hours ago, Tezz said:

The backlash with XBIOS in general is saddening to see. Nobody needs negativity. Barbarians multiload makes use of it too. Reading the angry response Fandal got with use its use in Stunt Car Racer after his hard work was a off-putting to continue working on my own projects.

I like Xbios, it's really easy to work with. (It's just confusing to get started using it though!).

 

Too bad about slow speed on 1050 drives...

Share this post


Link to post
Share on other sites
9 hours ago, xxl said:

I want it all, I want it all, I want it all, and I want it now.

 

👍

Queen if I'm not mistaken...

Share this post


Link to post
Share on other sites
2 hours ago, rensoup said:

 

So how often are you decompressing code ? i did some tests with a heatmap and I thought most of the code was accessed pretty much all the time (except the screen building perhaps)

 

Thanks for all the info, it had been bugging me for a while 😀

 

All the code is decompressed on startup. But at some point I couldn't fit in all of the code anymore, so I started to keep it in ROM and call it there directly. I think the only self-modifying code I came across was the bitmap drawing routines. All the game logic seems to be safe to run from ROM.

 

So there are two parts, the resident code in RAM, and an additional 8K ROM bank. I also initially removed all the jump tables, but then I re-added one just for the parts of the code that were kept in the ROM bank.

Edited by mrsid
  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, mrsid said:

All the code is decompressed on startup. But at some point I couldn't fit in all of the code anymore, so I started to keep it in ROM and call it there directly. I think the only self-modifying code I came across was the bitmap drawing routines. All the game logic seems to be safe to run from ROM.

I did spot a few in coll.s and ctrlsubs.s. (labeled sm...) . Would be interesting to know if you left those in ROM and the game actually ran fine ?

Share this post


Link to post
Share on other sites
18 hours ago, mrsid said:

Well, once I decided to go via the cartridge route, I didn't have to optimize for memory size anymore, so I optimized for speed instead. So e.g. the level blueprint data is no longer compressed and aligned to bank boundaries, to allow it to be accessed directly (about 40K).

Also all the background drawing (and clearing) code is unrolled (about 64K).

The title screen picture and the title cards are stored as bitmaps (about 72K).

The music code and data is about 8K (data streams converted from MIDI data, no patterns or other size optimizations).

The cutscene (princess room) background bitmap is another 10K.

The animation frames for the kid are aligned to fit into hardware sprites, so they take up about 40K per direction.

The frames for guard, fat guard, skeleton and vizier are about 8K each, for each direction.

Dungeon and Palace backgrounds are about 16K each.

The main part of the code is 24K compressed, and some code (about 8K) is kept uncompressed in ROM, to execute it directly (such as the AI and sword fighting logic).

There's also a little intro with a manual reader (about 24K).

The sound effects are in their own 8K bank.

The rest is miscellaneous stuff and alignment overhead, and some free space to save the game state to the flash.

 

The characters are drawn using hardware sprites, and need to be re-masked whenever they move, so it seemed easier to build up the whole mask first as part of the initial screen draw, instead of having to figure out the part of the screen that needs to be used for masking by walking the image lists again. I'm sure the other way round might have worked as well, but it's essentially another speed vs. memory trade-off.

 


 

ok. Now dumb question by lame coder like me.... why is it not finished then? Are you at the glorious 80% and stalled? :)

Share this post


Link to post
Share on other sites
10 hours ago, rensoup said:

I like Xbios, it's really easy to work with. (It's just confusing to get started using it though!).

 

Too bad about slow speed on 1050 drives...

Me used it in Arsantica 2 and got the back lash, too. But it’s so cool loader that I would use it again. Who cares about real drive with all those SD drives.... ;)

 

Arsantica 3 was even better using custom SIO loader HARD used in their demos which I of course was not the best way either but I wanted to use a custom loader once in lifetime and to play music while loading finally.... ;)

 

@Tezz you should continue.... who cares about the pack as we want Barbarian...

  • Like 2

Share this post


Link to post
Share on other sites
11 hours ago, rensoup said:

Too bad about slow speed on 1050 drives...

there will be more good things in xB, a foretaste of this is described here: 

 

  • Like 4

Share this post


Link to post
Share on other sites
3 hours ago, Heaven/TQA said:

ok. Now dumb question by lame coder like me.... why is it not finished then? Are you at the glorious 80% and stalled? :)

he's talking about the c64 version which was released years ago 😏

3 hours ago, Heaven/TQA said:

Me used it in Arsantica 2 and got the back lash, too. But it’s so cool loader that I would use it again. Who cares about real drive with all those SD drives.... ;)

 I do, it's magical even though I sold mine decades ago 😀

Edited by rensoup

Share this post


Link to post
Share on other sites

And here's another gif: The first iteration of the main sprite code!

 

 

pop3.avi.gif.b77b832aeb15f573d80d9359cd3a8626.gif

 

There was no clipping, no screen save/restore so it looked a little funny... I was thrilled though 😀

 

I was still using the BBC artwork... next preview will feature @TIX 's artwork!!

 

  • Like 15

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...