NTR wasn't used to remove the outline, it was used to take the screenshot. I guess I didn't really clear that up in my postYou don't have to use NTR to use the remove the outline or the mystery machine patch, so both work on O3DS and N3DS
NTR wasn't used to remove the outline, it was used to take the screenshot. I guess I didn't really clear that up in my postYou don't have to use NTR to use the remove the outline or the mystery machine patch, so both work on O3DS and N3DS
OH! Sorry for my misunderstanding :3NTR wasn't used to remove the outline, it was used to take the screenshot. I guess I didn't really clear that up in my post
Yeah, wasn't very clear with that, so i fixed my post to clear that up. Plus it helped really show the difference when I compared the images side-by-sideOH! Sorry for my misunderstanding :3
So all the patches work, ect ect. Nothing broken. What I was more interested in was the "Remove Outline" in Pokemon S/M. So of course I had to setup NTR to take some screenshots and to properly show it working. Which was nice because I ran into the same battle both before and after the patch was applied
I also tested the patch on an old3DS to see if it would actually work. Which I am pleased to say, it does indeed work on an old3DS as well. So reboot patches and the remove outline patch do not conflict with each other and will work on an old3DS.
These tests we preformed on an actual physical copy of the game and both systems are running the latest OFW.
Here's the screenshots from my new3DS
Then I would like to properly thank those two! Because it's an interesting feature.Thank @Gray_Jack and @Kitlith for porting the S&M stuff (god, we need a better abbreviation for Sun/Moon.) That was 100% them.
Also, reboot and individual loader patches literally can't conflict. They're not the same thing at all. If an application patch failed, you'd be stuck at the 3DS logo. And if reboot and loader conflicted...the OS would never boot.
Can someone give me the latest commit compiled?
I still cannot get rid of the segmentation fault error T-T
This is the one I've been using/testingHere's the latest nightly (as of now).
https://github.com/gnmmarechal/skeith/tree/master/rel
Also, my Corbenik CFW Updater: RE will be updating from this file.
Can someone give me the latest commit compiled?
I still cannot get rid of the segmentation fault error T-T
--- a/makerom/Makefile
+++ b/makerom/Makefile
@@ -1,5 +1,5 @@
# Sources
-SRC_DIR = . polarssl libyaml
+SRC_DIR = . polarssl
OBJS = $(foreach dir,$(SRC_DIR),$(subst .c,.o,$(wildcard $(dir)/*.c)))
# Compiler Settings
@@ -18,7 +18,7 @@ else
else
# Linux
CFLAGS += -Wno-unused-but-set-variable
- LIBS +=
+ LIBS += -lyaml
endif
endif
--- a/makerom/yaml_parser.h
+++ b/makerom/yaml_parser.h
@@ -1,6 +1,6 @@
#pragma once
-#include "libyaml/yaml.h"
+#include "yaml.h"
typedef enum
{
This is going to sound borderline nonsense, but I got makerom segv'ing after rebuilding devkitpro on a fresh gentoo install. After stepping through the crash, it seemed libyaml was doing something fucky with libc. Unbundling and compiling against my system libyaml fixed it.
Code:--- a/makerom/Makefile +++ b/makerom/Makefile @@ -1,5 +1,5 @@ # Sources -SRC_DIR = . polarssl libyaml +SRC_DIR = . polarssl OBJS = $(foreach dir,$(SRC_DIR),$(subst .c,.o,$(wildcard $(dir)/*.c))) # Compiler Settings @@ -18,7 +18,7 @@ else else # Linux CFLAGS += -Wno-unused-but-set-variable - LIBS += + LIBS += -lyaml endif endif --- a/makerom/yaml_parser.h +++ b/makerom/yaml_parser.h @@ -1,6 +1,6 @@ #pragma once -#include "libyaml/yaml.h" +#include "yaml.h" typedef enum {
EDIT: gbatemp kinda wrecked the patch formatting, but it's not that hard to manually edit the files.
IT WORKS!!!!!
THANKS SO MUCH!!!
I would never think that the problem was the makerom
You could have Travis build every commit from upstream and upload nightlies as releases on this repo.All right, updated.
https://github.com/gnmmarechal/skeith
You could have Travis build every commit from upstream and upload nightlies as releases on this repo.
@chaoskagami
Would be possible to make the chainloader load elf files using libctr9? It's not a request, it's just a curiosity question
Possible? Yeah.
There's a number of things I have to fix before I can update the libctr9 submodule and even start on that, though. There's been a number of API breaks, not to mention the rather nice console subsystem that does most of what draw.c does in a far cleaner manner (but not all of it, sadly.) This is going to be a *really* gradual process.
Thanks for the info, it's really good to know that. I hope one day it became a feature, not that it will change too much for the end user, but I think elf loading is better than binaries loading (I may be wrong on that).