MSXgl – A new C game library for MSX | MSX Resource Center (صفحة 11/27)

بواسطة aoineko

Paragon (1132)

24-02-2022, 20:52

Bravo jbikker!
The fluidity of the rotation is quite impressive.
I'm interested in your sources because I had started a 3D module for my library a few years ago (based on precomputed transformation table) and I'm still thinking about releasing it one day.

بواسطة Grauw

Ascended (10818)

24-02-2022, 21:34

jbikker wrote:

I made a spinning 3D cube using your framework:

https://www.cs.uu.nl/docs/vakken/magr/cube3d.rom
(file kindly hosted on the servers of my university ;) ).

Ah, my alma mater! Very nice! Do you apply any interesting types of optimisations?

بواسطة jbikker

Resident (44)

24-02-2022, 21:41

Here's a repo:

https://github.com/jbikker/msx3d

Optimization tricks have been detailed in the readme, and of course can be found in the code.

بواسطة Grauw

Ascended (10818)

24-02-2022, 22:03

Ah, I see! Must’ve been nice to code up the data generation.

بواسطة ARTRAG

Enlighted (6976)

25-02-2022, 09:15

jbikker wrote:

Here's a repo:

https://github.com/jbikker/msx3d

Optimization tricks have been detailed in the readme, and of course can be found in the code.

Thanks for the credits! Your work is awesome, I think that sharing your encoder would be very interesting as well.

Optimising the sprites to mask colour spill in screen2 has been done, but only for still frames, never for animations.
This is my encoder (as matlab script)
https://github.com/artrag/Screen-2-converter-with-sprite-ove...

بواسطة jbikker

Resident (44)

25-02-2022, 09:30

I will add the encoder, but it's not pretty.

بواسطة jbikker

Resident (44)

25-02-2022, 09:54

A folder 'encoder' has been added inside the msx3d repo, which contains the c++ project that produces frames.h and tiles.h based on the output of a simple software rasterizer.

Note that the software rasterizer is 'by the book', implementing sub-pixel accuracy as taught by FATMAP2.TXT, in case anyone remembers. The result is a very smooth animation, even at low resolution.

The software rasterizer is a reduced version of the full rasterizer that you can find in one of my other repos.

بواسطة aoineko

Paragon (1132)

25-02-2022, 13:11

2 tips regarding customasm.h :
- You can remove __sdcccall(0) then src will be in HL and dest in DE. No more stack manipulation. \o/
- Not an optimisation, but you can replace your lists of outi with the OUTI(x) macro (based on the .rept sdasz80's directive). OUTI(10) replace 10 outi instructions.

Not tested:

void VDP_WriteVRAM_16K_4( const u8* src, u16 dest )
{
	src, dest;
	__asm
		ld		a, e
		di
		out		( P_VDP_ADDR ), a
		ld		a, d
		out		( P_VDP_ADDR ), a
		ld		c, #P_VDP_DATA
		OUTI(3)
		ei
		outi
	__endasm;
}

And I think you should re-activate interruption before your last outi, not before your the second out.

بواسطة jbikker

Resident (44)

25-02-2022, 14:36

Ah yes, that does make those functions a bit shorter. The SDCC manual doesn't mention this behavior btw (https://gist.github.com/Konamiman/af5645b9998c802753023cf1be...); are the arguments still stored on the stack as well? That sounds like manual inlining could bring some extra performance here..

The OUTI(X) thing gives me an error during compilation.

By the way, is there a way to do some sort of a page flip in this screen mode? And would it be possible to change the sprite attribute data start address?

Too many questions, I probably need to read the red book again. :)

بواسطة ARTRAG

Enlighted (6976)

25-02-2022, 15:13

If you switch to SDCC v4.2 http://sdcc.sourceforge.net/doc/sdccman.pdf , for functions that do not have variable arguments this is the rule: The first parameter is passed in a if it has 8 bits. If it has 16 bits it is passed in hl. If it has 32 bits, it is passed in hlde. If the first parameter is in a, and the second has 8 bits, it is passed in l; if the first is passed in a or hl, and the second has 16 bits, it is passed in de; all other parameters are passed on the stack, right-to-left.