MSXdev21 #30 - PAC-01 | MSX Resource Center

Par gdx

Enlighted (6437)

31-08-2021, 10:10

Oh, great!!!

Par Latok

msx guru (3960)

31-08-2021, 11:09

Love this

Par mzoran

Master (161)

31-08-2021, 12:11

sleek

Par ARTRAG

Enlighted (6977)

31-08-2021, 12:21

Awesome!

Par KdL

Paragon (1485)

31-08-2021, 12:22

cool!

Par tfh

Prophet (3430)

31-08-2021, 13:08

Fantastic!

Par Parn

Paladin (854)

31-08-2021, 13:24

Great game! Very impressive and fun.

Par defdanny

Scribe (391)

31-08-2021, 13:27

very neat and polished graphics! I experience strange graphic bugs when trying to play it on WebMSX.

Par tfh

Prophet (3430)

31-08-2021, 13:32

defdanny wrote:

very neat and polished graphics! I experience strange graphic bugs when trying to play it on WebMSX.

That is not a bug... You have to avoid the green glitch/void
Just Google a bit for Pacman 256 glitch

Pac-Man 256 - Beware of the glitch

Par jltursan

Prophet (2619)

31-08-2021, 13:30

Oh, wow, it's absolutely full of details. This year the jury is going to have a bad time...

Par tfh

Prophet (3430)

31-08-2021, 13:30

jltursan wrote:

Oh, wow, it's absolutely full of details. This year the jury is going to have a bad time...

I pitty this years jury... They have a hell-of-a-job in front of them. I can only hope that they don't have any personal life.

Par defdanny

Scribe (391)

31-08-2021, 13:32

you got me! its by purpose. sorry that I did not get the joke first.
what a nice sense of humour!

Par tfh

Prophet (3430)

31-08-2021, 13:43

defdanny wrote:

you got me! its by purpose. sorry that I did not get the joke first.
what a nice sense of humour!

Don't worry, I totally missed it at well, while it is mentioned in the manual.
I even wrote an e-mail to the creator of this game who pointed me in the right direction ;-)

Par ro

Scribe (5061)

31-08-2021, 13:54

defdanny wrote:

very neat and polished graphics! I experience strange graphic bugs when trying to play it on WebMSX.

meh, I know real man don't read manuals or RTFM.. but just to be sure, https://www.msxdev.org/2021/08/31/msxdev21-30-pac-01/

it will explain the green soup :)

Par Randam

Paragon (1431)

31-08-2021, 13:58

Yay an PACMAN 256 variant for MSX! I love the game. Only draw back is that there is no temporary powerups like in Pacman 256. But very cool game and nice change that you have to catch all the ghosts!

Par ren

Paragon (1947)

31-08-2021, 14:01

Nice! Played just a bit, some suggestions/ideas: perhaps a (vertical) map-progress meter would be a nice-to-have, and an Oh Shit! hack/patch (just for the life lost voice)?

Par santiontanon

Paragon (1832)

31-08-2021, 14:02

Very cool!! I played PACMAN 256 a lot on the iPad and now we have an MSX variant, with its own twist (capturing all the ghosts)! Very nice technically too!

Par Briqunullus

Paladin (770)

31-08-2021, 15:23

Playing this game is so much fun. Excellent job. And there's some nice technical tricks as well. I like that the large banners are see-through and you see the maze (soft) scrolling in the background.

Par kirem2

Supporter (5)

31-08-2021, 19:00

Incredible and beautiful, well done.

Par Fabio_acrs

Supporter (14)

31-08-2021, 19:31

Nice graphics and gameplay. Attention to the details. Well done.

Par CASDuino

Champion (358)

31-08-2021, 20:45

Dayum.
I looked at the screen shots and thought it must be MSX2, but no. That's seriously impressive.

Par Uninteresting

Champion (366)

31-08-2021, 20:58

1) That's now one game for every day of September.
2) This game is amazing.

Par CASDuino

Champion (358)

31-08-2021, 21:40

I've created CAS and TSX files for those who like it old school.
BLOAD"CAS:",R is the load command.

Download from here.

Par Grauw

Ascended (10821)

31-08-2021, 23:36

This is great! Super nice graphics, and creative gameplay!

Par Manuel

Ascended (19682)

01-09-2021, 00:16

This has amazing polish! The sound effect when you get closer to the green stuff at the bottom increases volume, for instance

Par Micha

Expert (110)

01-09-2021, 11:07

Thanks everybody for the positive feedback!
It has been great fun to program this game, and even more fun to play it now it is finished (or is it weird to play your own games?).
I've put a lot of time and effort in things that are not noticable right away, but that make it possible to play a very fast game, such as:
- the level design itself (I created horizontal "stops" everywhere);
- the steering of the character (if you put your joystick in the up-right diagonal, the character should be moving up, then right, then up, then right again, which is not trivial);
- keeping the time between joystick input and character on screen as fast as possible (so fast even modern consoles have a hard time doing this), thus avoiding any buffering;
- avoiding any stuttering, which would be killing for the gameplay, so even at 60 hz there are about 10.000 machine cycles unused each frame, to be absolutely 100% sure it never skips a frame.

To really benefit from all this I do recommend to play on a real msx with a crt-monitor. Even though the modern emulators are really, really good, the true smoothness of this game can only be experienced the old fashioned way... (but maybe I'm too much of a nostalgic purist). On the other hand, the game is very well playable on emulators and probably most people will not feel a difference at all.

I hope everybody enjoys playing PAC-01; and I can't wait to see a YouTube movie popping up with somebody eating all 6 ghosts in the fast game at Lightspeed 200%...

greets,
Micha

Par Micha

Expert (110)

01-09-2021, 11:21

ren wrote:

Nice! Played just a bit, some suggestions/ideas: perhaps a (vertical) map-progress meter would be a nice-to-have

You can see how far you are in the level in 2 ways:
1) The fruit comes up just before the half of the level and disappears just after the half of the level
2) on the total left of the screen (in the red dots) sometimes one, two or three horizontal bars come by. If it is one bar, then you are at 1/4th of the level, two bars means halfway, and three bars means 3/4th of the level.

Par ren

Paragon (1947)

01-09-2021, 12:03

Ah, nice!
So this is your 2nd entry in the compo right?

Regarding latency/lag, did you ever have a look at RetroArch with the blueMSX core? They've got some techniques implemented. I wonder how you would assess those / the performance in that emulator (making use of these mitigation techniques)? :)

Would the target machine for this game preferably be PAL or NTSC?
Game also looks nice with frsCoolColors btw ;)

Par mzoran

Master (161)

01-09-2021, 13:04

Just out of curiosity, as both of your games are graphically very sleek, what is your background ? Do you normally work as a designerm or did you have some help for drawing or coding ?

On a side note, I did try to run the game on a real machine (sofarun), but after the logo appears, computer just reboots. Perhaps it does not like being run from a subslot ?

Par Micha

Expert (110)

01-09-2021, 13:22

ren wrote:

Ah, nice!
So this is your 2nd entry in the compo right?

Yes it is; Raven was my first entry.

ren wrote:

Regarding latency/lag, did you ever have a look at RetroArch with the blueMSX core? They've got some techniques implemented. I wonder how you would assess those / the performance in that emulator (making use of these mitigation techniques)? :)

That second link about latency - that looks impressive, and it proves that emulation does not need to be delayed if implemented the right way. But most people don't change the refresh rate of their monitor when playing in an emulator; or they have input lag because of a wireless keyboard or joystick, etc. But as I said, most people won't even notice the difference, even with a 2 frame delay.

ren wrote:

Would the target machine for this game preferably be PAL or NTSC?

It doesn't really matter. The music speed is the same on both 50 and 60 Hz. Playing is 20% faster on 60 Hz, but only because on 50Hz the Z80 is waiting longer for the next VBlank. It wil go through exactly the same code and settings.
But it makes playing easier on 50 hz...

Par journey

Hero (577)

01-09-2021, 14:00

Micha wrote:

ren wrote:

Ah, nice!
So this is your 2nd entry in the compo right?

Yes it is; Raven was my first entry.

2 games, two masterpieces! WOW!

Par Timmy

Master (200)

01-09-2021, 14:01

I thought the cutscene was really funny.

Par ARTRAG

Enlighted (6977)

01-09-2021, 14:06

Raven was my preferred till now ;-)

Par Micha

Expert (110)

01-09-2021, 15:59

mzoran wrote:

Just out of curiosity, as both of your games are graphically very sleek, what is your background ? Do you normally work as a designerm or did you have some help for drawing or coding ?

Thanks; Since I was a child drawing and programming were hobbies; I have a background in applied science but since 5 year or so I am a fulltime coder / designer. I do all my projects completely alone, since making games like this is a creative process that I believe doesn't benefit from compromises...

mzoran wrote:

On a side note, I did try to run the game on a real machine (sofarun), but after the logo appears, computer just reboots. Perhaps it does not like being run from a subslot ?

Do you mean after the MSX-Logo appears or after the Arc8 Logo ?
For the slotselection I used the code from : https://www.msx.org/wiki/Develop_a_program_in_cartridge_ROM and it is the first thing the program does.
I am not familiar with SofaRun, I tested it on real hardware (multiple machines) with a MegaFlashRom cart without any problems...

Par tfh

Prophet (3430)

01-09-2021, 16:04

http://www.indieretronews.com/2021/08/pac-01-new-variation-o...

Par JMeric

Resident (51)

02-09-2021, 00:47

@Micha > Great games you've done for this msxdev'21 I'm jalous : a one man game maker

Par gdx

Enlighted (6437)

02-09-2021, 02:35

mzoran wrote:

On a side note, I did try to run the game on a real machine (sofarun), but after the logo appears, computer just reboots. Perhaps it does not like being run from a subslot ?

Sofarun and ODO doesn't support this ROM at all.
It works with the loaders that run the ROM by reset. (It requires a flash ROM or SRAM cartridge)

Par gdx

Enlighted (6437)

02-09-2021, 09:11

I have found what is causing the crash. This is a problem from loaders. RAM initialisation routine at 05166h crushes the stack because it is lower when disks are installed.

The solution is to find a loader that puts the stack to the same location as when a ROM starts up. ODO can run it finally if you press CTRL when loading until game starting.

By replacing the 27h byte with 15h at 028Bh in the file to initialize less RAM, the game seems to work with Sofarom. Micha can tell if changing this byte is really sufficient and if so, add a condition to initialize the RAM up to the top of free memory only, otherwise we have to test to see if the game works fully as well.

Quote:

For the slotselection I used the code from : https://www.msx.org/wiki/Develop_a_program_in_cartridge_ROM and it is the first thing the program does.

I looked at your routine, it's a little different but it seems to work. Your routine is one byte shorter.

Par Micha

Expert (110)

02-09-2021, 11:14

gdx wrote:

I have found what is causing the crash. This is a problem from loaders. RAM initialisation routine at 05166h crushes the stack because it is lower when disks are installed.

The first thing the program does after the Arc8 logo is filling the memory from &C000 to &E740 with zeroes. This RAM is used by the game and it cannot be shortened without cutting a piece of of the playfield. Above &E740 the program itself doesn't use memory. I thought I left a pretty safe margin there ?

gdx wrote:

By replacing the 27h byte with 15h at 028Bh in the file to initialize less RAM, the game seems to work with Sofarom. Micha can tell if changing this byte is really sufficient and if so, add a condition to initialize the RAM up to the top of free memory only, otherwise we have to test to see if the game works fully as well.

That 27h forms the 2740 bytes between &C000 and &E740 that are cleared. Lowering that number might seem to work, because the playfield will be totally overwritten later on. But if the stack gets lower than &E740, then the end of the playfield will be corrupted. and then you will get garbage from the top as well... and if you start to eat pixels in that garbage your stack will be trashed and the computer will likely crash. So lowering that byte to 15h will create even more nasty errors.

Par mzoran

Master (161)

02-09-2021, 11:42

With sofarun loader, initial stack is very likely in $Dxxx range.
Perhaps you can just set stack to $F380 if the code does not need access to disk routines, which I guess it does not.
That also requires you not to call previous H.TIMI hook.

Par gdx

Enlighted (6437)

02-09-2021, 12:11

Micha wrote:

I thought I left a pretty safe margin there ?

I think SofaRom needs to be fixed not your game, but You can still put the stack at &HE740 for your game to work despite the Sofarom bug if you want.

Par Micha

Expert (110)

02-09-2021, 12:11

gdx wrote:

I have found what is causing the crash. This is a problem from loaders. RAM initialisation routine at 05166h crushes the stack because it is lower when disks are installed.

Looking a little bit further into it, could the problem be solved by initialising the stack pointer in my program? I don't do that right now... Probably the SP is low because of Sofarun in combination with Disk-Rom or so, but since I don't use disks in my game, I can initialise the SP anywhere that is convenient. Or do I miss something here ?

Par Micha

Expert (110)

02-09-2021, 12:16

Micha wrote:

Looking a little bit further into it, could the problem be solved by initialising the stack pointer in my program? I don't do that right now... Probably the SP is low because of Sofarun in combination with Disk-Rom or so, but since I don't use disks in my game, I can initialise the SP anywhere that is convenient. Or do I miss something here ?

Ah now I read the previous comments... I agree that programs or games shouldn't be updated to work with other software (because that is the beauty of MSX), but this is a very small update (and having read a little more into it, maybe even good practice to initialise the stack pointer), so I might do this and use it in my future games as well...

Par gdx

Enlighted (6437)

02-09-2021, 12:22

Yes, the problem should be fixed if the stack pointer is placed above 0E740h.
Also check your ROM slot selection routine to be sure it works for the secondary slots as well.

Par djh1697

Paragon (1736)

03-09-2021, 20:56

This such an addictive game! No criticisms at all, perhaps some colourful voice saying "Oh Shit!" when you lose a life would have been super cool, but I love it, pity the judges!

Par Maggoo

Paragon (1218)

03-09-2021, 23:49

Very cool way to revisit a classic and the level of polish is outstanding! Labor of love for sure.

Par MsxKun

Paragon (1134)

04-09-2021, 17:26

Micha wrote:

gdx wrote:

I have found what is causing the crash. This is a problem from loaders. RAM initialisation routine at 05166h crushes the stack because it is lower when disks are installed.

Looking a little bit further into it, could the problem be solved by initialising the stack pointer in my program? I don't do that right now... Probably the SP is low because of Sofarun in combination with Disk-Rom or so, but since I don't use disks in my game, I can initialise the SP anywhere that is convenient. Or do I miss something here ?

Yep, you can't assume the stack pointer is at any exact adress on MSX Better put it yourself anywhere you want.

Par MsxKun

Paragon (1134)

04-09-2021, 17:28

Micha wrote:

Looking a little bit further into it, could the problem be solved by initialising the stack pointer in my program? I don't do that right now... Probably the SP is low because of Sofarun in combination with Disk-Rom or so, but since I don't use disks in my game, I can initialise the SP anywhere that is convenient. Or do I miss something here ?

Ah now I read the previous comments... I agree that programs or games shouldn't be updated to work with other software (because that is the beauty of MSX), but this is a very small update (and having read a little more into it, maybe even good practice to initialise the stack pointer), so I might do this and use it in my future games as well...

Safety first! And it's safer to put the stack yourself than trust the user, or MSX-DOS, or whatever, to don't mess with things

Par MsxKun

Paragon (1134)

04-09-2021, 17:36

Micha wrote:

gdx wrote:

I have found what is causing the crash. This is a problem from loaders. RAM initialisation routine at 05166h crushes the stack because it is lower when disks are installed.

The first thing the program does after the Arc8 logo is filling the memory from &C000 to &E740 with zeroes. This RAM is used by the game and it cannot be shortened without cutting a piece of of the playfield. Above &E740 the program itself doesn't use memory. I thought I left a pretty safe margin there ?

As always on MSX. Depends!!
For a start, for what you say, the game won't work on 8k RAM MSX machines, like Casio. So it could be a good idea to add a note saying it requires 16kb of RA M Then, as said before.. we have loaders and stufffs.... Sometimes MSX can be a mine field But nothing that can't be solved easily and round a nice funny game in the way!

Par theNestruo

Champion (430)

07-09-2021, 09:50

Maybe I'm a little bit too late to the party, but please take a look to my cartridge initialization routine, a simplified (less conditional code and optional parts removed) version of the MSXlib version.
The routine includes stack initialization, slot selection (for both 32kB and 48kB ROMs), CPU mode, RAM check and zeroing, and H.TIMI hook initialization... please take what you need ^_^

Par Micha

Expert (110)

09-09-2021, 10:09

theNestruo wrote:

Maybe I'm a little bit too late to the party, but please take a look to my cartridge initialization routine, a simplified (less conditional code and optional parts removed) version of the MSXlib version.

Oh great, thanks. This will be helpfull!

Par gdx

Enlighted (6437)

09-09-2021, 12:29

This routine is not useful for ROM games that do not support disks. It is the loader which must reproduce the adequate environment to make the ROMs work.

Par AxelStone

Prophet (3199)

09-09-2021, 13:36

This game is fantastic, really polish, a profesional production at all.

Par theNestruo

Champion (430)

09-09-2021, 14:42

gdx wrote:

This routine is not useful for ROM games that do not support disks.

Can you elaborate, please?

Par gdx

Enlighted (6437)

09-09-2021, 17:19

When a machine language game starts from a ROM, it is always in Z80 mode, it is always screen mode 0 or 1, the disks are not installed and the stack is always in the same place. Of course, this can change if you insert a cartridge into a lower slot, but just removing it will solve this problem.

Only the amount of RAM and the slot in which it is located can be different depending on the MSX model used.

The slots configuration is like this:

or:

So game ROM loaders must at least recreate an equivalent environment as much as possible to run an image of this kind of ROM.

Par martin

Supporter (7)

10-09-2021, 01:10

Great game! I enjoy so much playing it.

Par gdx

Enlighted (6437)

10-09-2021, 02:31

Note that there may be different slot configurations because a ROM can also boot between 00010h and 3FFEh, or C010h and FFFEh if its size exceeds 32kB/48kB or thanks to possible mirrors. These cases are not common.

MSXdev21 #30 - PAC-01

Share

Related content

Commentaires (57)