logs archiveBotHelp.net / Freenode / #3dsdev / 2015 / September / 15 / 2
furyhunter
compatible with llvm3.5 using opt
by doing that, it doesn't make dependencies on llvm's intrinsics from libcompiler-rt
rather, when I use arm-none-eabi-as to assemble the generated .s, it will make dependencies on gcc's instead
yuriks
sounds like it compiles fast
furyhunter
unfortunately cargo-build crashes after emitting the ir correctly, so that's a little obnoxious
yuriks
lol
furyhunter
YES it worked
okay, let's try something a little more elaborate
bah, hackndev's core crate is busted. how annoying.
oh... oh I'm so close
undefined references to gfxInitDefault, gfxSet3D, gfxExit for some reason
;_;
...!
missing symbols notwithstanding (commented them out), I just got it building successfully. Now to test
aaaand it's no good
sigh... closer at least
profi200
What are you trying exactly?
furyhunter
compiling a somewhat trivial rustlang demo to 3ds
oh sad day, as soon as I link into ctrulib it breaks
profi200
Ok.
furyhunter
lmfao i should have gone to bed hours ago
okay okay this time I got no-landing-pads working maybe
nNNIT WORKED
yuriks: it FUCKING works, except aformentioned gfx functions, will write up tomorrow, passing the fu*k out zzzzzzzz
https://github.com/Furyhunter/new3ds proof of concept
linkmauve1
yuriks, any reason for using inline ASM instead of atomic_uintptr_t?
furyhunter
wait... hold the fu*kin phone, is LTO breaking sh*t?
nm
linkmauve1
Or well, _Atomic u32*.
profi200
linkmauve1:Why do it in sw if you can do it in hw?
linkmauve1
profi200, what do you mean? The compiler is the one that will translate the C code into ASM for you.
In the end the same instruction will be emitted, but usually with better scheduling and register allocation.
profi200
But i bet it will not generate these instructions but will use some sw solution instead.
linkmauve1
profi200, indeed, gcc 4.9 as provided by devkitarm will use __sync_synchronize, but gcc 5.2 provided by ArchLinux will emit proper x86 atomics.
gcc 5.2 from ALARM, on my server, does use the dmb instruction.
So I guess its just that devkitarm provides a too old gcc that didnt properly implement C11.
Or not properly, but with a software implementation on ARMv6.
profi200
The solution used now should work fine.
linkmauve1
Yeah, but it isnt elegant in any way.
profi200
Also why the second __asm__ volatile()? Maybe i'm not familiar with the syntax of that stuff.
He is tsill in that same block.
Oh, nvm.
vaguerant
Dag, was about to bug aliaspider.
Snes9x-Next in RetroArch 3DS seems to have the reverse problem to CatSFC.
Setting 1:1 PAR seems to result in 256*239 at all times, even running 224-line games.
OK, so I think more accurately, the SNES viewport size depends solely on "crop overscan", not what the core is actually pushing.
With crop overscan ON, the viewport is set to 256*224 and everything is scaled correctly (overscan cropping crops to 224 lines, so it works all around).
With crop overscan OFF, RetroArch Snes9x just sets the viewport to 256*239, which works for those games which run 239, but not for the majority of SNES titles.
If you don't mind losing 15 lines, leaving crop overscan ON will give the most convenient result in that you don't need to fix scaling at every turn.
CatSFC does not appear to respect "crop overscan" at all, 239-line games simply display the full image (at 224 lines, by default, since CatSFC is hardcoded).
These seem like deeper issues than anything that has gone wrong in the 3DS port, but I'd have to test on another platform to see if the same is true there.
profi200
CatSFC is not really the emu of choice. Nice for very slow platforms but if you want accuracy it is sh*t.
It spams speed hacks all over the pace.
vaguerant
Yeah, of course. It's the only SNES core in RetroArch that's ever likely to run full speed, though.
Have fun playing bsnes on 3DS. :V
profi200
It already does but with all the speedhack sh*t it runs too fast.
vaguerant
Turn on vsync.
profi200
It was already last time i checked but it had no effect it seems.
It was running too fast. But there was no tearing caused from turned off VSYNC. Just the sh*tty scaling.
vaguerant
The scaling is fixed now, get the nightly again.
profi200
Can not try yet. Later. Thought that is low priority?
vaguerant
I believe aliaspider is mostly just patching up whatever he feels like doing as he goes.
aliaspider, more whining about SNES viewports but I think this is a RetroArch issue, not a 3DS port issue: http://pastie.org/private/h6pzkym2hhcd4ikojtqmvg
aliaspider
the game in question was an USA game running with 256x239 right ?
vaguerant
Nope, on Snes9x-Next with crop overscan OFF, all games (including 224-line games) run at 239 lines when displayed using the 1:1 PAR setting.
aliaspider
it could be that the resolution detection is based on PAL or NTSC and the overscan setting only
vaguerant
But I was testing NTSC games, yes.
aliaspider
the resolution doesn't change per grame in snes9x, snes9x always pushes 224 either 239(or was it 240 ?) depending on the overscan setting
vaguerant
It doesn't look that way on 3DS. If you set crop overscan OFF then load a 224-line game, you can see that it's scaled to fill 239 lines.
voguerunt
Pinged out, sorry if I missed anything after my last message.
vaguerant
Left is how Super Mario Bros. looks with "crop overscan" ON, right is how SMB looks without "crop overscan" OFF: https://i.imgur.com/brGAKqZ.png (mockup scaled shot since there's no GPU screenshots currently)
Mario All-Stars runs 224-line (in the NTSC releases anyway, I think they actually did switch it up to 239 for PAL).
Uh, *with, I double negatived there.
Damn it, didn't notice you got disconnected too.
[01:27:10] <vaguerant> Left is how Super Mario Bros. looks with "crop overscan" ON, right is how SMB looks with "crop overscan" OFF: https://i.imgur.com/brGAKqZ.png (mockup scaled shot since there's no GPU screenshots currently)
[01:27:55] <vaguerant> Mario All-Stars runs 224-line (in the NTSC releases anyway, I think they actually did switch it up to 239 for PAL).
In mainline Snes9x, the resolution definitely does change per-game. I don't know if things have been done to the RetroArch core to change that.
aliaspider
crop overscan will just mimic the hidden lines on an old tv set, I thought this was a bug like the one with catsfc
it is working as intended in my opinion.
vaguerant
The problem is when crop overscan is turned off, no additional lines are being added to the picture of 224-line games.
The output is still 224 lines, but RetroArch scales it to fit 239.
aliaspider
let me test that
snes9x right ?
vaguerant
Snes9x-Next, yeah.
It's worth noting that running 224-lines is literally a hardware thing on the SNES, it's not that emulators are strictly "cropping" anything when they run 224.
Games can tell the system they're running 224 and the SNES will center them and put the extra lines in, they don't have to be handled at all by the game.
aliaspider
oh yeah you're right, that looks wrong
vaguerant
It's different to the NES where everything ran 240 all the time, whether games used all the lines or not (many NTSC games left them blank, but there's no hardware trick to make the system do that for you as a developer, you just have to tell it to leave the first and last 8 lines blank if you want to do that.
aliaspider
must be a bug in my video driver then
vaguerant
It's not a 3DS bug.
I just tested on desktop RetroArch.
Same thing.
profi200
Looks like the mystery is solved but through infos of another leaked SDK :| https://github.com/profi200/Project_CTR/pull/1
The CPU speed on N3DS is toggled with an exheader flag.
vaguerant
804MHz?
aliaspider
oh
yeah I was wondering the same
and ninjahx 2 overwrote that flag by error xD ?
*ninjhax
profi200
Nope, somehow it runs at fullspeed no matter under which title your hb runs.
« prev 1 2 3 4 5 next »