Grauw’s RPG in development

페이지 10/25
3 | 4 | 5 | 6 | 7 | 8 | 9 | | 11 | 12 | 13 | 14 | 15

By Grauw

Ascended (9392)

Grauw의 아바타

04-04-2018, 14:32

DarkSchneider wrote:

@sd_snatcher I see you are in my group, those who like to follow the standards. I also recommended to copy the VDP.RD and WR to somewhere in RAM and use them instead hardcoding the values.

I’m keeping VDP.RD and WR in mind to eventually use, since there is that Spanish MA-20 clone with V9958 now. Not committing to that though at this time. I’ll also keep the BIOS ISR running so that H.KEYI and H.TIMI stay active, although I do shorten it by setting INTCNT and SCNCNT to 0.

But sorry not going to use the BIOS to access keyboard / joystick / FM / PSG / etc. Just not going to happen. I’d much rather waste my cycles on having a nice code structure Wink.

Quote:

About the IM2 ISR, for a MSX-DOS environment I think it is not safe to read S#0, because it will be reset and bypassing the system ISR is not recommended, 0038H should be called from the IM2 ISR. It is not the same to set S#2 at first into the ISR, and then do all the commands work with S#2 already set?

All my code runs on the main loop though, on VBlank* I just set some base registers and update the palette which the main loop has prepared.

* Actually that’s not on VBlank but at line interrupt 212, and going to increase it to 240 orso to avoid palette tear while fading. I will have more line interrupts in the future btw, at least one for when the conversation UI is on screen, possibly more for visual effects.

msd wrote:

IIRC on msx2+ (or was in turbo r) the ports for the VDP are standardized. (should verify this in the msx2+ standard). If this is the case you don't need to store the VDP ports in ram.

I know that’s being passed around, I myself heard it from Guyver, but I’ve never actually seen any official documented statement about that. But nevertheless assuming it’s true, then indeed one of the benefits of making MSX2+ software is that it allows me to hardcode the ports.

But as I mentioned there is that Spanish MA-20 clone with V9958 use case now. Those users chose to buy hardware which they knew a lot of software doesn’t support, so I’m not feeling obliged to worry about it. But for me a consideration is that it may increase the audience able to run my game a bit.

By Grauw

Ascended (9392)

Grauw의 아바타

04-04-2018, 21:15

Grauw wrote:

Pre-selecting status register 1 [for screensplits] may be needed to get them tight, but let’s see.

Ah actually, after setting the split one line early, I’d want to poll HR to get it tight, which is in status register 2 so that’s a perfect default.

By MOA

Champion (293)

MOA의 아바타

04-04-2018, 21:50

DarkSchneider wrote:

About the IM2 ISR, for a MSX-DOS environment I think it is not safe to read S#0, because it will be reset and bypassing the system ISR is not recommended, 0038H should be called from the IM2 ISR. It is not the same to set S#2 at first into the ISR, and then do all the commands work with S#2 already set?

IM2 is a nice way to quickly test a custom ISR; my ISR was just quickly put together to test what would happen if S#2 were to be the default selected VDP status register. I didn't consider it as shippable code or anything Smile

By MOA

Champion (293)

MOA의 아바타

04-04-2018, 22:28

Grauw wrote:

Email is in my profile Smile.

Ok, sent! Smile

Grauw wrote:

Yeah the map size, I was thinking of either just hardcoding it to 64x64 or have only a few size options. But I'll wait deciding until I've actually gotten the scale right and made some maps.

Also for testing player collision, the cheapest way is to actually not calculate the tile position from x/y coordinates at all, I can just determine the tile data pointer of the character once at the start of the level (when teleporting), and then offset the position as the player moves about and test the surrounding tiles (inc / dec for x, add / sub width*2 for y). So maybe it’s not so bad to just keep the multiplication and size flexibility.

Yeah, you're right, that would be an even better solution. I didn't look at the 'big picture' too much, so just did peephole optimizations a compiler would do to see how much I could win that way. Just had fun counting cycles and thinking of simple alternatives Smile Take them with a grain of salt.

By MOA

Champion (293)

MOA의 아바타

04-04-2018, 22:37

Grauw wrote:
Grauw wrote:

Pre-selecting status register 1 [for screensplits] may be needed to get them tight, but let’s see.

Ah actually, after setting the split one line early, I’d want to poll HR to get it tight, which is in status register 2 so that’s a perfect default.

Good news then. Like sd_snatcher I'm surprised this wasn't chosen as the default by the BIOS developers.

By sd_snatcher

Prophet (3367)

sd_snatcher의 아바타

04-04-2018, 23:26

Grauw wrote:

But sorry not going to use the BIOS to access keyboard / joystick / FM / PSG / etc. Just not going to happen. I’d much rather waste my cycles on having a nice code structure Wink.

It's your hobby, you know. Smile

I don't wan't to sound defiant or anything, so please read these questions as purely technical:

1) How much percent slower per frame you estimate that your game would become if it used the BIOS to read the keyboard/joysticks instead of direct I/O? I don't mean the specifically the joystick/keyboard subroutine, but the entire amount of code your game runs per frame.

2) How much more memory would it require?

By Grauw

Ascended (9392)

Grauw의 아바타

04-04-2018, 23:54

I think it’s rather a matter of, currently I have around 30% of frame time left. If I add a palette fade without precalculated values, it costs me 3-4%. I still need to do game logic, and tile animations, and screen splits, and a music replayer.

If at the end I have time left I could look at using the BIOS more (fairly simple for e.g. the keyboard) and see if it fits the frame budget. And I might. But then again, who would I be spending that time for? Nobody benefits from it. And to make time for the BIOS calls I may have to negatively affect the structure of the program with optimisations, making the code less reusable for a next project. Why would I want to do that?

In this game a lot will be going on, at 60 fps, and I already have a lot of work to do before release, so… it’s about the lowest on my priority list.

p.s. It’s fine to make suggestions about these things, and I don’t totally ignore them really, but I’m just being clear about my priorities. So you know what suggestions will resound with me, and what suggestions will just result in a “maybe” or a plain “naahh” Smile.

By sd_snatcher

Prophet (3367)

sd_snatcher의 아바타

05-04-2018, 00:03

The use of the BIOS leaves a world of future possibilities open, you know. Nifty tricks like NandemoSCC or SofaRun (disk emulation, automatic joyMega support) wouldn't have ever been possible with just software if the games used only direct I/O like a ZX-Spectrum or C64.

For example, similar tricks can be used to redirect the keyboard routines to a simple PS/2 keyboard interface, for those who lost the original keyboard of their machines, without requiring yet-another-I/O-CPU-that-runs-faster-than-the-Z80 to do the translation.

By sd_snatcher

Prophet (3367)

sd_snatcher의 아바타

05-04-2018, 00:16

Quote:

p.s. It’s fine to make suggestions about these things, and I don’t totally ignore them really, but I’m just being clear about my priorities. So you know what suggestions will resound with me, and what suggestions will just result in a “maybe” or a plain “naahh” Smile.

It's perfectly fine with me. You always express this it in a friendly way. From my side, I can say that it's always that: suggestions and perspectives. In the end, it's your free time, your hobby, your motivation. Only you can say what drives you to sit and code.

By Grauw

Ascended (9392)

Grauw의 아바타

05-04-2018, 00:48

Just did a quick test, using the BIOS ISR key scanning costs me 2.5% CPU time (60,000 cycles per frame really is not a lot, I keep getting reminded Crying), and it scans less frequently, with more latency.

Anyway like other things, if it’s something I’m going to look at, it will be near the end of the project. Right now structure and flexibility allowing me speedy coding without spending too much time optimising, and constant awareness of the frame budget are the most important to me. As I progress I will also gain more clarity on what the code needs to do and in which ways I can. Finding ways to do things smart rather than fast. But at the moment there’s just too many question marks to commit to things that I know will cost me, and foremost the game features are the most important to achieve at this point.

페이지 10/25
3 | 4 | 5 | 6 | 7 | 8 | 9 | | 11 | 12 | 13 | 14 | 15