MEGA65: Add nybl16 colour mode #239
Conversation
|
Hmm, something went wrong here :( It seems some TEXTUTRE_ macros wanted to be renamed SCREEN_ ... again :-O |
targets/mega65/vic4.c
Outdated
| @@ -243,18 +243,20 @@ static void vic4_update_sideborder_dimensions ( void ) | |||
| if (REG_CSEL) { // 40-columns? | |||
| border_x_left = FRAME_H_FRONT + SINGLE_SIDE_BORDER; | |||
| if (!REG_H640) | |||
| border_x_right = FRAME_H_FRONT + TEXTURE_WIDTH - SINGLE_SIDE_BORDER - 1; | |||
There was a problem hiding this comment.
Here for example, your PR want to rename TEXTURE_WIDTH back to SCREEN_WIDTH, though in theory you should have for now the state where SCREEN_WIDTH (and HEIGHT) is renamed to TEXTURE...
There was a problem hiding this comment.
Uhmmm... i dont even remember touching that...
There was a problem hiding this comment.
I'm a bit clueless, to be honest :( OK, maybe it was not a good idea from me to merge my changes first to you, but it still does not explain, how things changed back to SCREEN_ ... when I have no such string in the whole mega65 subtree any more ... So how I my PR changed things backwards? It does not make any sense for me :-O
There was a problem hiding this comment.
Something got mixed, in my uncomitted vic4.h there were SCREEN_WIDTH and TEXTURE_WIDTH both present. Now I have the synced vic4.h with only TEXTURE_WIDTH present, changed the only 3 occurrences in vic4.c and all it's going well. Go figure what happened.
| @@ -1065,6 +1063,22 @@ static void vic4_render_fullcolor_char_row ( const Uint8* char_row, int glyph_wi | |||
| } | |||
|
|
|||
|
|
|||
There was a problem hiding this comment.
Sorry for the question again, just make it clear :) So the part after this comment ( https://github.com/lgblgblgb/xemu/pull/239/files/55e202c05494a99e4b5bedca17b6145ed6dbe3a2#r614328716 ) looks like what I expected. What about the changes before? Are those really intended? I can't see it's connected to the implementation of the nybl mode video. Sorry for the so much confusion here, this turned out to be a very strange situation though the change itself for nybl mode is not so complex or anything in its own ...
There was a problem hiding this comment.
Looking at the file history, that comments were suited for better debugging the NTSC/PAL mode change.
There was a problem hiding this comment.
Yes but the !in_hypervisor again changed position what I worry for, but if you say it's intended that way, of course I believe you ;)
There was a problem hiding this comment.
I think it's the correct position -- may be the performance regression was due to this? e.g: recalculating modes on every frame access. The regressed output should have a lot of VIC4: border top=xxx etc.
|
OK, I've merged hopefully it's fine ;) I'll check the performance now etc, what you guessed about the problem. Thanks. |
Nybl16-color plus your own fixes.