Homebrew [Release] SDL-3DS 1.2.15 - Simple DirectMedia Layer for 3DS

[Badda]

Quick qustion: SDL_NumJoysticks() is returning 1 - even on a N3DS. However, there should be two joysticks - the C-pad and the C-stick.
How can I get the C-stick as a joystick?

 

[nop90]

Quick qustion: SDL_NumJoysticks() is returning 1 - even on a N3DS. However, there should be two joysticks - the C-pad and the C-stick.
How can I get the C-stick as a joystick?

You have to customize the SDL code to handle the C-pad. If you try you should find that it's very easy.

 

[Badda]

You have to customize the SDL code to handle the C-pad. If you try you should find that it's very easy.

Ok, thanks for clarification.
One more question: I'm currently porting a software to 3DS which uses the top screen initialized with SDL_SetVideoMode(SDL_TOPSCR). I would, however, like to add some own stuff on the bottom screen (not just console text but graphics). If I create another SDL_Surface with SDL_SetVideoMode(SDL_BOTTOMSCR), the topscreen surface is not working anymore. How can I have two separate SDL_Surfaces - one for top, one for bottom?

 

[nop90]

Ok, thanks for clarification.
How can I have two separate SDL_Surfaces - one for top, one for bottom?

You should look at second post of this thread:

- SDL_DUALSCR: draws the upper half of the video device on the top screeen and the lower half on the bottom screen

you can also look at some of my ports on github for reference.

Using SDL_SetVideoMode(SDL_DUALSCR) you can make a surface of 320x480, so the upper 320x240 will be used for top scren (with black lateral bands) and the lower 320x240 will fil the bottom screen.

This is good if you want that sprites moves continuosly from bottom and top screen. If the two screen ae used for separate views (i.e. game and menu) you'll have to handle drawing rects for moving sprites to control that part of one screen is not drawn on the other.

You can also define a 400x480 screen, this way part of the bottom screen surface will be not visible. But this is a waste of memory and CPU (SDL is very slow on 3ds).

The last option is to use 320x480 with SDL_FULLSCREEN flag so to stretch the top screen to 400x240, while the bottom screen wll remain not stretched.

I used this option to port games with an original resolution of 320x240, like in my Zelda ports, where the main game is on top screen stretched and the menu is always visible on the bottom screen.

 

[Badda]

You should look at second post of this thread:



you can also look at some of my ports on github for reference.

Using SDL_SetVideoMode(SDL_DUALSCR) you can make a surface of 320x480, so the upper 320x240 will be used for top scren (with black lateral bands) and the lower 320x240 will fil the bottom screen.

This is good if you want that sprites moves continuosly from bottom and top screen. If the two screen ae used for separate views (i.e. game and menu) you'll have to handle drawing rects for moving sprites to control that part of one screen is not drawn on the other.

You can also define a 400x480 screen, this way part of the bottom screen surface will be not visible. But this is a waste of memory and CPU (SDL is very slow on 3ds).

The last option is to use 320x480 with SDL_FULLSCREEN flag so to stretch the top screen to 400x240, while the bottom screen wll remain not stretched.

I used this option to port games with an original resolution of 320x240, like in my Zelda ports, where the main game is on top screen stretched and the menu is always visible on the bottom screen.

Ok, thanks for the hints. I figured as much looking on your port of Amphetamin. I guess, the software that I want to port, relies on having its own screen and has no built-in ways to display in parts of a larger screen - must validate that though. Hope, I will not need to get into the guts of the software to change that ...

 

[nop90]

Ok, thanks for the hints. I figured as much looking on your port of Amphetamin. I guess, the software that I want to port, relies on having its own screen and has no built-in ways to display in parts of a larger screen - must validate that though. Hope, I will not need to get into the guts of the software to change that ...

You can make a copy of the surface structure and make the data field to point at the first byte of the second half of the surface bits buffer.

Should work.

 

[NightScript]

I wonder if you can make a port of SDL to the original DS

 

[nop90]

I wonder if you can make a port of SDL to the original DS

There is already. But with different approach and no more maintaied.

To be honest my version too is no more maintained, but at least it's (should be) compatible with latest devkitARM changes.

About coding for the DS, I don't know very well the DS toolchain, and at the moment I'm more interested in Atari Lynx developement. Probably I'll back to 3DS when it will be a forgotten console.

 

[Badda]

You can make a copy of the surface structure and make the data field to point at the first byte of the second half of the surface bits buffer.

Should work.

Ok, got it working :-) But I really did have to get into the emulator internals ...
You might want to add another software to your list of things based on your SDL port: https://gbatemp.net/threads/release-vice3ds-c64-emulator.534830/

One more thing: I can't get the C-Stick or ZL/ZR buttons working. I bound them to a key with SDL_N3DSKeyBind but no event fires when I press the buttons. Do you know what I can do?

 

[Badda]

One more thing: I can't get the C-Stick or ZL/ZR buttons working. I bound them to a key with SDL_N3DSKeyBind but no event fires when I press the buttons. Do you know what I can do?

Sorry, it works - I'm stupid

 

[Badda]

You have to customize the SDL code to handle the C-pad. If you try you should find that it's very easy.

I checked your source - the only file I need to adjust to get the D-pad and C-stick working as a joystick is src/joystick/n3ds/SDL_sysjoystick.c, right?

... and I'm getting an error when trying to compile your SDL version:
libtool: link: arm-none-eabi-gcc -march=armv6k -mtune=mpcore -mfloat-abi=hard -mtp=soft -O3 -g -mword-relocations -std=gnu++11 -fno-rtti -fno-exceptions -fomit-frame-pointer -ffast-math -ffunction-sections -D_3DS -I/opt/devkitpro/portlibs/3ds/include/freetype2 -D_GNU_SOURCE=1 -ffunction-sections -fdata-sections -march=armv6k -mtune=mpcore -mfloat-abi=hard -mword-relocations -DARM11 -D_3DS -I/opt/devkitpro/portlibs/3ds/include/SDL -I/opt/devkitpro/libctru/include -o showfont showfont.o -specs=3dsx.specs -march=armv6k -mfloat-abi=hard -specs=3dsx.specs -march=armv6k -mfloat-abi=hard -L/opt/devkitpro/portlibs/3ds/lib -L/opt/devkitpro/portlibs/armv6k/lib -L/opt/devkitpro/libctru/lib ./.libs/libSDL_ttf.a -L/opt/devkitpro/portlibs/3ds -lfreetype /opt/devkitpro/portlibs/3ds/lib/libSDL.a -lcitro3d -lctru -lm
arm-none-eabi-gcc.exe: fatal error: c:/devkitpro/devkitarm/bin/../lib/gcc/arm-none-eabi/8.3.0/../../../../arm-none-eabi/lib/3dsx.specs: attempt to rename spec 'link' to already defined spec 'old_link'
compilation terminated.

Any ideas on how to fix that?

 

[nop90]

You should use the SDL version in devkitARM. The code is the same (don't think someone updated it) but all the dependancies to build it are updated.

EDIT: I see that devkitPRO site is down.

 

[Badda]

You should use the SDL version in devkitARM. The code is the same (don't think someone updated it) but all the dependancies to build it are updated.

EDIT: I see that devkitPRO site is down.

Thanks, using the SDL version that comes with devkitARM works :-)

Would you please take a quick look at the following issue that I am facing?
With my code, I simply want to display a png-image on the screen, no scaling involved. However, the image shown on the screen with the code below always comes out blurry, the colors are off and there are some strange artefacts. Here the code:

SDL_Init(SDL_INIT_VIDEO);
SDL_Surface *screen = SDL_SetVideoMode(400, 240, 24, SDL_HWSURFACE);
SDL_Surface *image = IMG_Load ( "/image.png" );
SDL_BlitSurface ( image, NULL, screen, NULL );
SDL_Flip(screen);

The image below shows the original png-image within the grey box on the left (enlarged - each black stripe is one pixel wide, original dimensions are 11x11px) and what the screen shows after executing the code above on the right. I checked the pixel data of both image and screen surface - they both look good. Seems like the issue occurrs when the screen surface is rendered to the physical 3DS screen - there are probably some unneccessary filters applied. What can I do to get the image on the screen "as is"?

 

[Badda]

Thanks, using the SDL version that comes with devkitARM works :-)

Would you please take a quick look at the following issue that I am facing?
With my code, I simply want to display a png-image on the screen, no scaling involved. However, the image shown on the screen with the code below always comes out blurry, the colors are off and there are some strange artefacts. Here the code:

SDL_Init(SDL_INIT_VIDEO);
SDL_Surface *screen = SDL_SetVideoMode(400, 240, 24, SDL_HWSURFACE);
SDL_Surface *image = IMG_Load ( "/image.png" );
SDL_BlitSurface ( image, NULL, screen, NULL );
SDL_Flip(screen);

The image below shows the original png-image within the grey box on the left (enlarged - each black stripe is one pixel wide, original dimensions are 11x11px) and what the screen shows after executing the code above on the right. I checked the pixel data of both image and screen surface - they both look good. Seems like the issue occurrs when the screen surface is rendered to the physical 3DS screen - there are probably some unneccessary filters applied. What can I do to get the image on the screen "as is"?

View attachment 164872

After a couple of rounds of researching, I found out the following:
- The artefacts are the remnants of a mouse cursor partly hidden by the image (lol)
- to prevent the blur you just have to change one single line of code

--- a/VICE3DS_SDL/src/video/n3ds/SDL_n3dsvideo.c
+++ b/VICE3DS_SDL/src/video/n3ds/SDL_n3dsvideo.c
@@ -460,7 +460,7 @@ int hh= next_pow2(height);
 
     // Setup the textures
     C3D_TexInit(&spritesheet_tex, hw, hh, this->hidden->mode);
-    C3D_TexSetFilter(&spritesheet_tex, GPU_LINEAR, GPU_NEAREST);
+    C3D_TexSetFilter(&spritesheet_tex, GPU_NEAREST, GPU_NEAREST);
 //    C3D_TexBind(0, &spritesheet_tex);
    
     runThread = true;

Will you still merge pull requests on github?

One more thing - just to inform you. I ported the VICE C64 emulator to 3DS using your great SDL port. Thanks for that!
https://gbatemp.net/threads/release-vice3ds-c64-emulator.534830/

 

[realWinterMute]

Will you still merge pull requests on github?

The SDL port is being maintained at https://github.com/devkitPro/SDL/tree/3ds-sdl-1.2, PRs much appreciated.

Nice work on the vice port

 

[Klairm]

I'm getting this error -> https://pastebin.com/Gt75iGa2
i installed sdl via pacman 3ds-sdl

 

[MrHuu]

I'm getting this error -> https://pastebin.com/Gt75iGa2
i installed sdl via pacman 3ds-sdl

It seems it can't link to citro3d.

How do you have your libraries linked in your makefile?

For example:

# Libraries needed to link into the executable.
#---------------------------------------------------------------------------------
LIBS := -lSDL_image -lSDL_mixer -lvorbisidec -logg -lmikmod -lSDL -lmad -lz -lcitro3d -lctru -lm
#---------------------------------------------------------------------------------

Make sure to link citro3d after SDL.

 

[Klairm]

It seems it can't link to citro3d.

How do you have your libraries linked in your makefile?

For example:

# Libraries needed to link into the executable.
#---------------------------------------------------------------------------------
LIBS := -lSDL_image -lSDL_mixer -lvorbisidec -logg -lmikmod -lSDL -lmad -lz -lcitro3d -lctru -lm
#---------------------------------------------------------------------------------

Make sure to link citro3d after SDL.

Ye I managed but forgot to edit my problem, I should had read better the post, I wasn't linking citro3d, thanks anyway!

 

[nguyengiabach1201]

I can not install that, I need your help, sir.