Skip to content

Psp ps2#235

Draft
freshollie wants to merge 13 commits intomainfrom
psp-ps2
Draft

Psp ps2#235
freshollie wants to merge 13 commits intomainfrom
psp-ps2

Conversation

@freshollie
Copy link
Collaborator

No description provided.

Copy link
Collaborator

@JaceCear JaceCear left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have not looked at the rendering code.
Otherwise, please adjust/discuss! :)

} else {
track->repeatCount = 0;
track->cmdPtr += sizeof(u8) + sizeof(u8 *);
track->cmdPtr = track->cmdPtr + sizeof(u8 *);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this changed from += 5(32bit) / 9(64bit) to 8?

And if this is indeed correct behavior, it can be downsized to += sizeof(u8 *). If it is correct.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just had a look at the original assembly.
The way it was before is correct (+= 5 in the original), so please revert it back!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was a mistake, oops

#if PLATFORM_WIN32 && !PLATFORM_SDL
#define RENDERER_SOFTWARE 0
#define RENDERER_OPENGL 1
#define RENDERER_SOFTWARE_FAST 2
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a fan of having 2 software renderers.
Especially considering it's to-be-removed anyway, adding another label here is extra complexity imo.

We can replace the old rendering with the faster one (leaving comments intact if possible) and if bugs occur we'll figure out, why.

My intention with these #defines was specifically to list different backends here.

Comment on lines +106 to +107
#define PSP_SCREEN_W 480
#define PSP_SCREEN_H 272
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are those actually nowhere defined in the PSP SDK?

If they are, remove these and use the SDK ones instead!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines -262 to -264
// Every GBA frame we process the SDL events and render the number of times
// SDL requires us to for vsync. When we need another frame we break out of
// the loop via a return
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No reason to be less verbose in the comment, I'd prefer keeping the old one.

Comment on lines +563 to +566
#define BTN_TRIANGLE 12
#define BTN_CIRCLE 13
#define BTN_CROSS 14
#define BTN_SQUARE 15
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a recommendation, I think calling them BTN_FACE_LEFT|TOP|RIGHT|BOTTOM would make code using face buttons more portable.

Here I'd also want you to check, whether the SDK defines these or not, and use those defines if they do.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had a look but it doesn't seem to (if we use the SDL interface)

// Handle horizontal and vertical tile flipping
if (entry & (1 << 10))
tileX = (TILE_WIDTH - 1) - tileX; // H-flip
tx = 7 - tx;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using magic numbers instead of TILE_WIDTH is less explicit.

Comment on lines +1248 to +1259
uint32_t tileDataOffset = tileNum << 5;
uint32_t pixelByteOffset = (ty << 2) + (tx >> 1);
uint8_t pixelPair = bgtiles[tileDataOffset + pixelByteOffset];

uint8_t pixel;
if (tileX & 1) {
pixel = pixelPair >> 4;
} else {
pixel = pixelPair & 0xF;
}
uint8_t pixel = (tx & 1) ? (pixelPair >> 4) : (pixelPair & 0xF);

if (pixel != 0) {
line[x] = pal[16 * paletteNum + pixel] | 0x8000;
line[x] = pal[(paletteNum << 4) + pixel] | 0x8000;
}
} else { // 8 bits per pixel
uint32_t tileDataOffset = tileNum * TILE_SIZE_8BPP;
uint32_t pixelByteOffset = tileY * TILE_WIDTH + tileX;
uint32_t tileDataOffset = tileNum << 6;
uint32_t pixelByteOffset = (ty << 3) + tx;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the compiler actually not optimize these multiplies to bitshifts?
Even agbcc does, and that's an OLD compiler...

Comment on lines 653 to 875
@@ -872,7 +872,7 @@ NONMATCH("asm/non_matching/engine/sub_80039E4.inc", bool32 sub_80039E4(void))
return TRUE;
#endif

#if (RENDERER == RENDERER_SOFTWARE)
#if (RENDERER != RENDERER_OPENGL)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we keep RENDERER_SOFTWARE_FAST (which as I said I would not prefer), please add that as extra case, instead of != RENDERER_OPENGL, because it's more explicit!
Otherwise change it back to original.

Comment on lines 927 to 942
@@ -939,7 +939,7 @@ bool32 ProcessVramGraphicsCopyQueue(void)
if ((graphics->src != 0) && (graphics->dest != 0))
#endif
{
#if (RENDERER == RENDERER_SOFTWARE)
#if (RENDERER != RENDERER_OPENGL)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we keep RENDERER_SOFTWARE_FAST (which as I said I would not prefer), please add that as extra case, instead of != RENDERER_OPENGL, because it's more explicit!
Otherwise change it back to original!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

Comments