Homebrew [RELEASE] ctrQuake - Quake 1 port

[MasterFeizz]

Looks great!

One suggestion: When pushing the toggle button the lower screen will switch between different types of layouts. For example:
1. Keyboard on the lower screen. (Just like on your picture)
2. Lower screen filled with black pixels (just like @elhobbs stuff) besides the toggle button (I prefer this mode)
3. Keep the color scheme of the lower screen intact, but remove the keyboard
4. The last one is probably very difficult. But it is the one I want most. Move/clone/mirror/duplicate/or any other method to make the two menu bars visable at the lower screen. But at the same time have the gameplay window at 400x240

1 and 3 are what I have now, I don't really like the 2 idea but I guess its just blanking the bottom screen. 4 at the moment would really hurt the performance

 

[SLiV3R]

1 and 3 are what I have now, I don't really like the 2 idea but I guess its just blanking the bottom screen. 4 at the moment would really hurt the performance

Yup. 2 is doing black pixels/blanking. If it is much trouble with coding that, you could perhaps copy elhobbs or Rinnegatamante blanking? But it is your project, so the decision is yours!


I know number 4 would hurt performance. But I believe that the N3DS could handle it! (Even though it would result in slightly lower fps, I think I would prefer this mode)

 

[MasterFeizz]

Yup. 2 is doing black pixels/blanking. If it is much trouble with coding that, you could perhaps copy elhobbs or Rinnegatamante blanking? But it is your project, so the decision is yours!


I know number 4 would hurt performance. But I believe that the N3DS could handle it! (Even though it would result in slightly lower fps, I think I would prefer this mode)

Blanking is easy. I will only try to move the hud to the bottom if I'm successful with the performance tweak I'm trying to implement

 

[SLiV3R]

Blanking is easy. I will only try to move the hud to the bottom if I'm successful with the performance tweak I'm trying to implement

Yay! That sounds like a possibility, at least

 

[MasterFeizz]

Yay! That sounds like a possibility, at least

I believe my idea will work, and if it does that means a decent boost in fps for the O3DS

 

[elhobbs]

Yup. 2 is doing black pixels/blanking. If it is much trouble with coding that, you could perhaps copy elhobbs or Rinnegatamante blanking? But it is your project, so the decision is yours!


I know number 4 would hurt performance. But I believe that the N3DS could handle it! (Even though it would result in slightly lower fps, I think I would prefer this mode)

I only did that so that I could still have some stdout stuff print on the bottom screen. It worked out well for heretic3ds because it has the perfect amount of space for the automap on the bottom screen. Heretic3ds uses 3D hardware rendering so it was a little easier to move.

 

[SLiV3R]

I only did that so that I could still have some stdout stuff print on the bottom screen. It worked out well for heretic3ds because it has the perfect amount of space for the automap on the bottom screen. Heretic3ds uses 3D hardware rendering so it was a little easier to move.

Ok! My first choice (if I may dream) in all these wonderful ports is moving the hud to the lower screen. Then I actually prefer the Heretic3ds alternative, to make the lower screen black, besides the little square

Edit: It is always good with alternatives, we all prefer different settings

 

[Arseface_TM]

I don't think showing the "shift" symbols full size is necessary, if they were smaller it'd be easier to read.

I'm not a huge fan of touchscreen keyboards in the first place, but this looks pretty good. I especially like the generic buttons for binds.

 

[MasterFeizz]

I don't think showing the "shift" symbols full size is necessary, if they were smaller it'd be easier to read.

I'm not a huge fan of touchscreen keyboards in the first place, but this looks pretty good. I especially like the generic buttons for binds.

Shift symbols? The keyboard isn't used all the time, so the touch keyboard is the best way to go

 

[Arseface_TM]

Shift symbols? The keyboard isn't used all the time, so the touch keyboard is the best way to go

1 to !
2 to @
, to <
. to >

I have no idea what they're actually called.

Touchscreen keyboards are a personal preference thing. I like buttons more than touchscreens because of the physical feedback.

 

[MasterFeizz]

1 to !
2 to @
, to <
. to >

I have no idea what they're actually called.

Touchscreen keyboards are a personal preference thing. I like buttons more than touchscreens because of the physical feedback.

I have to render than the same size because of the low resolution

 

[Arseface_TM]

I have to render than the same size because of the low resolution

Hmm, then offset them to the right a bit. You have plenty of space in the keys.

 

[TarableCode]

1 and 3 are what I have now, I don't really like the 2 idea but I guess its just blanking the bottom screen. 4 at the moment would really hurt the performance

There's a rather easy/hacky way of doing that that I've done before on other projects. (non 3ds)
Have a buffer just big enough to hold the status bar and set the drawing buffer to it before the status bar is drawn, making modifications so that draws at 0,0 and not 0,whatever.

After that just copy it to a texture and render it on the bottom screen.
Shouldn't take tooooo much processing power to do, but haven't looked if you were using Citro3D or writing directly to the framebuffer.

 

[MasterFeizz]

There's a rather easy/hacky way of doing that that I've done before on other projects. (non 3ds)
Have a buffer just big enough to hold the status bar and set the drawing buffer to it before the status bar is drawn, making modifications so that draws at 0,0 and not 0,whatever.

After that just copy it to a texture and render it on the bottom screen.
Shouldn't take tooooo much processing power to do, but haven't looked if you were using Citro3D or writing directly to the framebuffer.

The buffer has to be rotated and looked up on a pallete before it can be copied to the framebuffer

 

[TarableCode]

It's probably faster to use Citro3D and copy it to a texture, no rotation needed plus you get "free" linear scaling.
I do hate the fact that there's no indexed colour modes though, that's pretty BS imho...

 

[MasterFeizz]

It's probably faster to use Citro3D and copy it to a texture, no rotation needed plus you get "free" linear scaling.
I do hate the fact that there's no indexed colour modes though, that's pretty BS imho...

I don't use citro3d, and citro3d would make it slower because of color palletes and tiling

Edit: If you are talking about hardware rendering, that is going to take some time to implement, and I probably won't use citro3d

 

[TarableCode]

Not really that much slower, if at all.
GX_DisplayTransfer takes an insignificant amount of time and you can have the source tiled for you.

You still need to do Indexed->RGB8 which is going to be the most expensive operation but you'd have to do that anyway.
Btw... If you figure out a fast way to do that lemme know because it's goddamn expensive especially on the o3ds.

 

[elhobbs]

Not really that much slower, if at all.
GX_DisplayTransfer takes an insignificant amount of time and you can have the source tiled for you.

You still need to do Indexed->RGB8 which is going to be the most expensive operation but you'd have to do that anyway.
Btw... If you figure out a fast way to do that lemme know because it's goddamn expensive especially on the o3ds.

I tried doing some tests to have the display transfer engine tile textures and it was really slow. The manual software copy/tile was considerably faster and the source didn't need to be in linear. Maybe I was doing something wrong...

 

[TarableCode]

I just did a quick test and it seems the max time in milliseconds to convert and upload a 512x384 framebuffer to RGB565 is around 10ms. It looks as if the display transfer is taking < 1ms, most of the heavy lifting is done by a simple lookup table but it takes the longest time.

I'd be interested to see how fast the alternative of drawing right to the framebuffer is.

 

[SLiV3R]

I couldn't care less whether the shift button is a little bit smaller or not