Tales of Popolon (new MSXDev'17 entry)

Page 8/20
1 | 2 | 3 | 4 | 5 | 6 | 7 | | 9 | 10 | 11 | 12 | 13

By wyrdwad

Paladin (931)

wyrdwad's picture

26-03-2017, 09:29

Since it sounds like you're going to be correcting bugs anyway, I figure I'll report this: when you first step onto floor 3, the text box that pops up says that the people's souls are "traped" -- one p instead of two.

Pretty minor typo, and very much in keeping with the time period (heheh), plus that particular line of text already extends all the way to the end of the text box. But you might have room for the word "trapped" if you move one word down to the next line?

Just mentioning this because I know if it were me, I'd want to catch every last little issue. Wink

-Tom

By pitpan

Prophet (3152)

pitpan's picture

26-03-2017, 10:16

Santi: as you have already included the Turbo-R R800 mode, do you think it would be possible to do the same with Panasonic MSX2+ with "turbo" mode? It would make the game nicer on these machines (3.57 MHz -> 5.37 MHz, +50% speed!) and the code to detect and setup is already done:

	LD	A,8
	OUT 	(040H),A	;out the manufacturer code 8 (Panasonic) to I/O port 40h
	IN	A,(040H)	;read the value you have just written
	CPL			;complement all bits of the value
	CP	8		;if it does not match the value you originally wrote,
	JR	NZ,Not_WX	;it is not a WX/WSX/FX.
	XOR	A		;write 0 to I/O port 41h
	OUT	(041H),A	;and the mode changes to high-speed clock

14 sweet bytes, code taken from MAP.

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

26-03-2017, 14:40

The more I look at this game the more impressed I am...

I was just thinking... (feel free to ignore if you wish) maybe the switch graphics in the game should be something like...

 ___
__|__
|___|

At the moment it seems to me that the fact that the switch direction is related to your viewpoint is quite disturbing especially in the "switch puzzle"

... BTW (not that it is likely or anything) but it is possible to get your self trapped inside a wall without possibility to do anything if you close the door while you are under it. Smile Maybe it would be better just to die in this case...

Maybe there could be also two different stairs... The one that there is now + a "black box" for "stairs down"

I don't know if you are interested about tR suport that much, but I just want to let you know that when you output two bytes to VDP right after each other the CPU halts when the second output is done... and this is not just a small hickup... it is more like a coffee break that makes R800 in this task even more slow than Z80... You could actually do 16bit x 16bit multiplication in between and it still would not take any more time!

As this is not especially MSX tR game I don't think this is a good reason to change code too much, but it is good to keep in mind that if there is something you can do between the outs to VDP without extra hassle, it is very good idea to do so in order to get "free speed" out of R800.

By santiontanon

Paragon (1639)

santiontanon's picture

26-03-2017, 16:15

@wyrdwad: oh, that was an easy one (I actually did have an extra character in that line). So, fixed in the repo (haven't updated the build yet, since I want to fix the other things in the to-do list first, but that'll be later in the week Smile )

@pitpan: After I removed a function I realized I was not using, I still have 40bytes left in the cartridge. So, I do have space for that indeed. Added to the to-do list! Smile

@NYYRIKKI: Thanks! Big smile and good point about the switches. I'll play around with some some alternative graphics and see if I can come up with something that looks nicer and does not have the "right-left" issue! And about being trapped in a wall, really?! oh! didn't realize that there was any switch that was that close to a door! Perhaps the easiest solution is just to move the switches away to prevent that. In that was the problem would be solved without using any extra bytes of code Smile

About the Turbo R, didn't know that! I don't think I'll worry too much about it for this particular game. But I'd like to keep working on the engine after I'm done with the game (perhaps for future games). So, I'm going to make a note of this! The current code renders everything to a buffer in memory and then copies it to the VDP. But from what you say, perhaps in Turbo R it'd be better to directly render to VDP, to use the time in between writes to do the calculations.

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

27-03-2017, 00:52

santiontanon wrote:

@NYYRIKKI: Thanks! Big smile and good point about the switches. I'll play around with some some alternative graphics and see if I can come up with something that looks nicer and does not have the "right-left" issue! And about being trapped in a wall, really?! oh! didn't realize that there was any switch that was that close to a door!

Well, it is really not a problem... I managed to do this on the fortress1 where there is this silver mirror in an empty room with a switch... I must say that I needed to shoot the switch with an arrow from a very tiny angle. It was not exactly easy, but I managed to do that. Smile I could imagine doing this on some other place would be easier.

Oh, and BTW sometimes you can see sprites trough the walls if you stand very near... This is not much of a problem either.

Quote:

About the Turbo R, didn't know that! I don't think I'll worry too much about it for this particular game. But I'd like to keep working on the engine after I'm done with the game (perhaps for future games). So, I'm going to make a note of this! The current code renders everything to a buffer in memory and then copies it to the VDP. But from what you say, perhaps in Turbo R it'd be better to directly render to VDP, to use the time in between writes to do the calculations.

Indeed... If you can do the writes without random access to VRAM it will greatly improve the performance when using R800. I've been told that the delay between VDP port accesses is 57 clocks, but I don't know how this number has been calculated... anyway it is a lot of time especially considering that simple commands on R800 use only clock or two.

By santiontanon

Paragon (1639)

santiontanon's picture

28-03-2017, 05:09

Yeah, I noticed the "seeing sprites through walls" issue. This is related to the way I check for "visibility" (which enemies/items) are visible from the point of view of the player. I might have some edge case wrongly considered there. I'll add it to my to-do list (yesterday I had a long 6 hour flight and I managed to get most of my to-do items done, so, only a couple more little things left for the next release, including looking at this issue Smile ).

By gdx

Enlighted (5591)

gdx's picture

28-03-2017, 06:55

The v.1.1.1 has been released:

https://github.com/santiontanon/talesofpopolon/releases

The joystick works now. :)

santiontanon wrote:

@gdx, really? is it less smooth on a real MSX?

Yes, it is obvious on MSX Turbo R.

By santiontanon

Paragon (1639)

santiontanon's picture

28-03-2017, 06:56

Also, I was trying to reproduce the issue reported by wyrdwad in an FS-A1WX MSX2+ loading the game via ODO, and I actually get an even worse error. When I try to do this in OpenMSX, the game seems to load fine, until you press space to start the game. Then it all goes crazy and the emulation stops telling me that I have set some unsafe PSG registers. The problem is that the raycasting goes nuts and renders over the music buffer, which then sends random commands to the PSG. But I'm surprised to see this behavior, since there is nothing special about the raycasting code...

What I am doing is just launching the MSX with the disk of MSXDOS1.21, then switching to a disk that only has ODO and the game rom, and loading it. So, my question is, what does exactly ODO do to load the ROM? I'm suspecting that something gets "funny" with the memory, then causing both the problems that wyrdwad reported and the one I am seeing. I'll keep trying to investigate what is happening in any case though.

By wyrdwad

Paladin (931)

wyrdwad's picture

28-03-2017, 09:42

santiontanon wrote:

Also, I was trying to reproduce the issue reported by wyrdwad in an FS-A1WX MSX2+ loading the game via ODO, and I actually get an even worse error. When I try to do this in OpenMSX, the game seems to load fine, until you press space to start the game. Then it all goes crazy and the emulation stops telling me that I have set some unsafe PSG registers. The problem is that the raycasting goes nuts and renders over the music buffer, which then sends random commands to the PSG. But I'm surprised to see this behavior, since there is nothing special about the raycasting code...

What I am doing is just launching the MSX with the disk of MSXDOS1.21, then switching to a disk that only has ODO and the game rom, and loading it. So, my question is, what does exactly ODO do to load the ROM? I'm suspecting that something gets "funny" with the memory, then causing both the problems that wyrdwad reported and the one I am seeing. I'll keep trying to investigate what is happening in any case though.

If it helps: I think the version of MSX-DOS I'm running odo from is 1.03, for some reason. No idea why or how I wound up with an outdated version of MSX-DOS, but somehow, I did. Wink

I can't imagine that would make any difference, honestly, but maybe memory is allocated differently in 1.21 than in 1.03?

Also, I'm not switching disks -- my MSX-DOS boot disk has odo and all the roms of the various games I've been checking out directly on it. A couple years back, I wrote up a front-end game selection menu in MSX BASIC that boots on startup, or you can just press Q to quit back to the DOS prompt if you want to do DOS-related things. I can send you a .dsk of it for testing, if you think that might help -- just drop me an email.

-Tom

By santiontanon

Paragon (1639)

santiontanon's picture

28-03-2017, 10:00

Ok, found what was causing the problem on my end!! (man, it was a stupid error! Big smile). There was a wild pointer in the code I wrote to support Turbo R machines that overwrote a single byte in the code. When running from ROM that's not a problem, since you cannot overwrite the ROM. But when loading the game with ODO, since the code is in RAM, that was overwriting a byte in the code, making it go wild!

wyrdwad: Could you check if this version solves the problem for you? https://dl.dropboxusercontent.com/u/3303662/ToP-ODO-v12.rom

If that doesn't do it, then I might send you an email for that test disk :)

Page 8/20
1 | 2 | 3 | 4 | 5 | 6 | 7 | | 9 | 10 | 11 | 12 | 13