Grauw’s RPG in development

Page 6/22
1 | 2 | 3 | 4 | 5 | | 7 | 8 | 9 | 10 | 11

By ren

Paragon (1273)

ren's picture

29-03-2018, 15:17

But.. Will there be chickens? Hannibal Face

By Grauw

Ascended (8507)

Grauw's picture

29-03-2018, 15:32

@ren Hmmm, I guess they are a staple...

DarkSchneider wrote:
Quote:

* Coordinate at the command end (SY*, DY*)

I don't know if that means the same line it ends, or the next one, so direct copies could be done without updating DY.

By the way, please also consider the original Yamaha application manual scan, where the phrasing is different from Eugeny’s edited version.

I think it means the line after it ends. As I understand it N is the number of lines it will draw, which is NY unless you try to copy across the maximum Y coordinate and it clips. So the end state is:

N = min( NY, MAX_Y - SY, MAX_Y - DY ) = typically NY
SY* = SY + N = typically SY + NY
DY* = DY + N = typically DY + NY
NY* = NY - N = typically NY - NY = 0

DarkSchneider wrote:

What is DYH?

With DYH I mean the high byte of the DY value. When I copy a (16, 4) tile to e.g. (0, 240), DY can end up as 100H, so I need to make sure it is 0.

I made two small errors, there should be no need to set DY for the column copies, only DYH, since the DY increment matches the one I want. For the row copies I also do need to set DYH, for the above mentioned reason.

By DarkSchneider

Paladin (879)

DarkSchneider's picture

29-03-2018, 15:43

OK DYH could be set to the fixed value depending on the page you are using for scrolling. I think it not adds much delay.

By hit9918

Prophet (2868)

hit9918's picture

29-03-2018, 16:41

        exx
        out (c),l       ;port 99
        out (c),h
        add hl,de       ;next line in vram
        exx
        outi            ;another pixel
        add hl,de       ;next line in RAM
        jp nz,loop
--
91 cycles

a port 99 setup for every pixel (!!!), THAT is what takes 30% cpu!

By Grauw

Ascended (8507)

Grauw's picture

29-03-2018, 16:53

Where is that code from?

By hit9918

Prophet (2868)

hit9918's picture

29-03-2018, 17:36

wait, the 30% cpu was about scrolling 4 pixel per frame?
that is a whole different thing

the code was borderfill on 9938 where the blitter is lost to scrollcopy.

By Grauw

Ascended (8507)

Grauw's picture

29-03-2018, 21:27

Ah, yeah scrolling diagonally 2 pixels / frame on V9958, 32 4x16 HMMM copies every two frames.

By Grauw

Ascended (8507)

Grauw's picture

30-03-2018, 00:10

Grauw wrote:

But my real grand plan to free up CPU time is to make the game run at 30 fps, while updating all the motion at 60 fps (scroll + sprite positions). This means the input handling, game logic, collision detection, tile animations, sprite animations and z-sorting, all this expensive stuff gets spread out over two display frames. This will give a lot more breathing room, and since the motion updates at a higher frequency, the game will still appear smooth.

To achieve the 60 fps motion, the main loop will always write two values for scroll and sprite positions, one for the current and one for the next frame. The ISR will pick the appropriate scroll position of the two, and update the sprite locations from one of two 128-byte RAM buffers. I think this is a fairly modest cost for smooth 60 fps motion.

Slight change of plans; instead of writing sprite attributes from a 128-byte RAM buffer on the ISR, I’m going to double buffer the sprite attribute table, write the attribute data each frame, the colour data every other frame, and use an YMMM command to copy the colour data from the first buffer to the second.

This way I can avoid updating VRAM from the interrupt handler, which is troublesome for two reasons; one, it adds a CPU cost of about 0.7 ms (4% frame time) each frame, but more importantly, accessing VRAM on the ISR either via port 98H or through VDP HMMC commands is troublesome because it conflicts with the main loop. If I use 98H I can’t use that on the main loop, and ditto for HMMC, plus it requires big di blocks around non-HMMC commands. The latter also messes with the command registers so I can’t do optimisations like we discussed earlier.

The 512-byte copy will take approximately 2.7 ms to complete (16% frame time, 8% on average), but since the VDP command engine is idle at that time anyway, it will increase the VDP parallelisation, incur virtually no CPU cost, and the ISR can return quickly. Additionally, all sprite routines can write to VRAM rather than some to RAM and some to VRAM. I think this will be better :).

By Grauw

Ascended (8507)

Grauw's picture

01-04-2018, 00:04

Also, after the idea a few posts back, I’m definitely going to use OUTI to set VDP registers on the ISR:

;
; VDP registers to set on VBlank
;
DisplaySettings: MACRO
	horizontalOffsetCharacters:
		db 0
		db 26 | VDP_REGISTER
	horizontalOffsetDots:
		db 0
		db 27 | VDP_REGISTER
	verticalOffset:
		db 0
		db 23 | VDP_REGISTER
	patternName:
		db 0
		db 2 | VDP_REGISTER
	spriteAttributeLSB:
		db 0
		db 5 | VDP_REGISTER
	spriteAttributeMSB:
		db 0
		db 11 | VDP_REGISTER
	spritePattern:
		db 0
		db 6 | VDP_REGISTER
	ENDM

; hl = this
DisplaySettings_ApplyHL:
	ld c,VDP_PORT_1
	REPT 14
	outi
	ENDM
	ret

Nice and quick, and easy to configure. Also there seems to be a nice path to extend this to an easy flexible screensplits system: have the last register set be the next screensplit line, and return a pointer to the next object.

By DarkSchneider

Paladin (879)

DarkSchneider's picture

30-03-2018, 09:19

It is probably the way intended to be used considering the OUTI Z80 instruction. Direct access for non-consecutive registers, and indirect for consecutive ones as OUTI count can be almost halved.
Also, using C instead hardcoding the numbre it complies with the MSX regulation. Instead VDP_PORT_1, shadow copy the ports listed on BIOS to somewhere in RAM and set C from there.

ld a, (vdp_port_1) ; now it as a RAM address
ld c, a
...

But remember also to update the register values in system variables, or you (or any other software in the case of DOS software with EXIT to prompt option, this is, a non-reset-to-quit software) will not be able to read their values. You could delay this and do it i.e. when any copy command to use that VDP working time.

Page 6/22
1 | 2 | 3 | 4 | 5 | | 7 | 8 | 9 | 10 | 11