logs archiveBotHelp.net / Freenode / #3dsdev / 2015 / September / 2 / 8
endrift
anyway I was wondering how you're accelerating drawing paletted images
StapleButter
in reality, I don't-- the idea involves fragment lighting but it's still a theory
the HW renderer just caches tiles as it encounters them
endrift
ugh
I guess if you have a sixteen stage TEV you can do that, but the 3DS does not
StapleButter
neither does it have indirect texturing, which could have worked
endrift
ugh
yuriks
Lectem: you could do it if you use heuristics to detect that a game was doing a "3d" effect using per-scanline rotation, but it would be very tricky and would probably break most of the time anyway (and you'd need a fallback)
StapleButter: I wonder if the procedural texture thing can't do that
StapleButter
given the LUTs and crap?
maybe
yuriks
the 3DS GPU still have many unexplored functions
StapleButter
depends on how big those can be though
yuriks
btw, does anyone know how the ZSNES "hi-res mode7" option worked?
StapleButter
doesn't it just antialias the mode7 graphics or somesh*t?
yuriks
did it interpolate coefficients between the scanlines or something?
StapleButter
dunno
yuriks
well, it doubles the resolution of mode7 layers
but it also worked for 3D plane effects, so it must've been doing something like that
Lectem
I dont know if I should PR my DSP stuff to ctrulib yet
StapleButter
considering DSP requires a signed binary, well
endrift
I do have plans for a renderer that caches tiles
eventually
but I haven't gotten there yet
I can never work up the willpower to work on it
problem though is that it'll take like 2 additional MB and I'm already low on RAM
Lectem
really?
but the 3ds has so much ram :3
endrift
I'm already reserving 32MB out of 56MB usable for a ROM
and then a bunch of that goes to video and audio buffers immediately
so I PROBABLY have 2MB to spare, but it's a bit tight
Lectem
aw, do you really need that much ram for the roms?
endrift
yes
e.g. Mother 3 is a 32MB game
and I don't do anything clever with mapping only parts of ROMs
due to the overhead that would introduce
Lectem
would the overhead be that big?
endrift
yeah actually
anyway looks like I have 8MB left in the heap after ROM loads, everything else is on the linear heap
I might be able to reduce the size of the linear heap
yuriks
oh, so conserving RAM is a priority? glad to know my overthinking is justified lol
endrift
but of that, ~400kB is reserved for savestates
well, possibly more due to how savestate loading works
yuriks
endrift: if you have space on the linear heap, you can just allocate crap out of that
endrift
yeah I should reduce the size of the linear heap if I can
but yeah 2MB shouldn't be a big problem
yuriks
like, the linear heap is as good if not better than the regular one, so xD
endrift
I ran into problems when I tried to put the ROM on the linear heap
Lectem
go full linear :p
endrift
plus most of my calls are to malloc directly
I use malloc for small-to-medium allocations and mapAnonymousMemory for large ones in the core
the latter is platform-defined
on *nix, it's mmap
on Windows it's VirtualAlloc
on 3DS, it's just malloc
yuriks
you can probably replace that with linearAlloc
endrift
it was linearAlloc for a while
if I make the normal heap 36MB and the linear heap 20MB I should be fine
I never free the ROM on the 3DS
it's just a reserved 32MB block
so I don't want it on the heap at all
but I ran into issues with putting it anywhere else
yuriks
20MB? what do you need all that for?
xyz
how much ram is usable on 3ds usermode?
endrift
leftover space for whatever allocations I want
yuriks
64MB for the hb exploits
endrift
like
the emulator doesn't allocate often
yuriks
endrift: I don't really understand
« prev 1 2 3 4 5 6 7 8 next »