Homebrew doom

  • Thread starter Thread starter elhobbs
  • Start date Start date
  • Views Views 208,121
  • Replies Replies 900
  • Likes Likes 34
Sound isn't working on my Old 3DS.

I modified the controls so I can use the circle pad. I noticed that if I just slightly touch it, it acts like I put it all the way. This is sorta annoying, any way to fix it?

Also, I'm running it as a CIA. Can you make a logo and change the name from "Sample Homebrew" to something else?
 
I don't understand why people try using old ports with the code of those being really old and non-SDL compliant.

As known from my work for the PSP, PS Vita and Wii I highly suggest using the Chocolate DOOM source port as it includes all games: DOOM, Heretic, Hexen and Strife. It also includes support for SDL graphics, SDL sound and OPL music, SDL controls, SDL networking via UDP as well as OGG / FLAC music via SDL.

Nothing is easier than that. I don't get it why people try messing with these old ports like PrBoom...
 
I don't understand why people try using old ports with the code of those being really old and non-SDL compliant.

As known from my work for the PSP, PS Vita and Wii I highly suggest using the Chocolate DOOM source port as it includes all games: DOOM, Heretic, Hexen and Strife. It also includes support for SDL graphics, SDL sound and OPL music, SDL controls, SDL networking via UDP as well as OGG / FLAC music via SDL.

Nothing is easier than that. I don't get it why people try messing with these old ports like PrBoom...
No one is trying to stop you from porting chocolate doom to the 3ds. It sounds like a great idea.

Seriously though - there are a million doom source ports. Id software used prboom for their iOS port - so that was about as far as I looked for selecting a version to port. I was looking for the least amount of effort to see doom in 3d on my 3ds. Chocolate doom doesn't exactly meet that requirement.
 
I was looking for the least amount of effort to see doom in 3d on my 3ds. Chocolate doom doesn't exactly meet that requirement.

Chocolate DOOM's goal is to be as close to the original as possible. That's why it is what it is and that's the reason why it doesn't include any specials like OpenGL or something else.

At least with the help of the developer of Crispy DOOM, I've been able to double the pixels seen on the screen to set the resolution up to 640 x 400. And by the way: Crispy DOOM is a Chocolate DOOM fork with a few extras.
 
AWESOME!!!!!!!! Oh it is so nice to have sound :D . Sound kind of stutters, but at least it is there
the stutter - it is a timer issue. I was using csnd to sync the playback buffer. apparently this does not work on newer firmware versions - somewhere above 4.4.
Chocolate DOOM's goal is to be as close to the original as possible. That's why it is what it is and that's the reason why it doesn't include any specials like OpenGL or something else.

At least with the help of the developer of Crispy DOOM, I've been able to double the pixels seen on the screen to set the resolution up to 640 x 400. And by the way: Crispy DOOM is a Chocolate DOOM fork with a few extras.
at the time I started porting this - sdl on the 3ds was not really an option. not sure what the state of it is at this point.
 
Well this Doom is pretty damn good so far. If someone else makes an attempt at Porting another Doom loader, would like to see the Circle Pad as the Forward/Back/Strafe Left-Right, C Nub as Look Up-Down/Turn Left-Right, L/R Cycle Weapons, ZL Aim, ZR Fire. Basically like how it is in Brutal Doom. Or take Doom Touch for Android.
Example: Screenshot_2015-04-18-13-43-52.png
 
The lack of icon and banner was bothering me, so I added them. I also added circle pad movement (the threshold needs a bit of adjusting though).

Here it is if someone else wants it:
https://github.com/raulbojalil/prboom3ds/raw/n3ds/prboom3ds.cia
there was already circle pad support. It is possible to configure this through the key bindings menu.

What you did is link the dpad and the circle pad together. the original implementation maps 3ds button presses to "keyboard" key events. the original implementation allowed the dpad and circle pad to be bound to a key individually.

the original code:
Code:
    { KEY_DRIGHT, KEYD_RIGHTARROW, 0 }, //bit 04

the modified code:
Code:
    { KEY_RIGHT, KEYD_RIGHTARROW, 0 }, //bit 04

this is the definition to KEY_RIGHT - which is just the dpad and the circle pad together
Code:
    KEY_RIGHT = KEY_DRIGHT | KEY_CPAD_RIGHT,

So, linking them together may have been your intended result but I would not call it enabling the circle pad. In fact this functionality was already possible because the key binding menu allows you to assign two keys to one action.
 
  • Like
Reactions: Akdul
there was already circle pad support. It is possible to configure this through the key bindings menu.

What you did is link the dpad and the circle pad together. the original implementation maps 3ds button presses to "keyboard" key events. the original implementation allowed the dpad and circle pad to be bound to a key individually.

the original code:
Code:
    { KEY_DRIGHT, KEYD_RIGHTARROW, 0 }, //bit 04

the modified code:
Code:
    { KEY_RIGHT, KEYD_RIGHTARROW, 0 }, //bit 04

this is the definition to KEY_RIGHT - which is just the dpad and the circle pad together
Code:
    KEY_RIGHT = KEY_DRIGHT | KEY_CPAD_RIGHT,

So, linking them together may have been your intended result but I would not call it enabling the circle pad. In fact this functionality was already possible because the key binding menu allows you to assign two keys to one action.


Ok, thanks for the clarification.
 
Ok, thanks for the clarification.
that being said - the current implementation really just treats the circle pad like an additional dpad - either on or off for events. a better approach (to me anyway) would be to remove the circle pad from the keysDown detection and read it properly using hidCircleRead. Then you could distinguish between small and large movements of the circle pad - walk vs run etc.
 
Old 3ds, when using the .cia I was using fw 4.2, I recently went back to 9.2 and tried it on ninjahax.
did you try the n3ds branch? it is a little odd csnd behaves differently on different firmwares. under 4.2 and 4.5 (maybe others) csnd allowed you to read the playback position for a looping sound. This does not work on 9.0 and up - not sure where in between it stopped working. I was relying on that playback position for sound mixing. I replaced reading the playback position with reading the system tick in the n3ds branch, but I have not updated the main branch yet.
 
that being said - the current implementation really just treats the circle pad like an additional dpad - either on or off for events. a better approach (to me anyway) would be to remove the circle pad from the keysDown detection and read it properly using hidCircleRead. Then you could distinguish between small and large movements of the circle pad - walk vs run etc.


Yeah, I agree, that would be best.
 
did you try the n3ds branch? it is a little odd csnd behaves differently on different firmwares. under 4.2 and 4.5 (maybe others) csnd allowed you to read the playback position for a looping sound. This does not work on 9.0 and up - not sure where in between it stopped working. I was relying on that playback position for sound mixing. I replaced reading the playback position with reading the system tick in the n3ds branch, but I have not updated the main branch yet.
Ill try compiling it, I'll see if it works
 

Site & Scene News

Popular threads in this forum