Hello, I'm having... probably the simplest easiest to fix problem there is? I can't figure it out though. I'm trying to build this, but it just says "no targets specified and no makefile found." I've installed DevkitPro/ARM and it's Windows so it set up the environment, I also installed Python 3.4.3. Do I need to tell Programmer's Notepad where to find things? I see that in the settings, Make doesn't have a Scheme, does it need one?
Generally speaking, DMA is set up to do fast transfers whenever there is some kind of interval blank period (where screen is not rendering, or video access is disabled), otherwise transfers are slow (depending on the channel priority given anyway). I/m not sure of 3DS, but at least it's that way on SNES and GBA/DS. Maybe nintendo did the same this time on 3DS. Can't be of more help ATM
Did you set up the "Make" tool yourself? Make sure that in the tool properties, the folder is set to $(ProjectPath)
What do you mean by "does not have a scheme"?
Return-oriented programming
https://en.wikipedia.org/wiki/Return-oriented_programming
Overly simplified version: When a program calls a function, it will first write down the current memory address (and some other info) on a call stack. When the function is finished, it will take the (newest) address on the call stack and jump back to there. Return-oriented programming uses certain techniques to overwrite the return address so that the program jumps "back" to a different place, so it will run code it's not supposed to.
A good program is of course protected against this, so you'd need a bug somewhere to actually make this work. It's definitely not something just everyone could do.
Guys, there's something I'd like to ask. I've just finished my first homebrew game for the 3ds and there's one bug that I just don't understand. I coded it so that you can quit the game at any time by pressing Start and Select at the same time and that works without a problem.....once. When I'm back in the home menu and then enter the game again the 3DS freezes when I try the Start and Select button combo again, idk what's wrong. Could somebody point me into the right direction here?
- Joined
- Nov 24, 2014
- Messages
- 3,162
- Trophies
- 2
- Age
- 29
- Location
- Bologna
- Website
- rinnegatamante.it
- XP
- 4,857
- Country
Yes, sorry >.<
Code:
memset(buf0, 0, 0x300);
memset(buf1, 0, 0x20);
aptOpenSession();
APT_PrepareToDoAppJump(NULL, 0, 0x0004003000009802LL, 0);
APT_DoAppJump(NULL, 0x300, 0x20, buf0, buf1);
aptCloseSession();That's basically my Quit function. buf0 has the size of 0x300 and buf1 has the size of 0x20, I just followed the app launch example in ctrulib. I can post the whole file if you want but it's all really messy, it's my first app on the 3DS and my second one in C++....
Is there a device unique ID accessible through ctrulib?
I thought that PS_GetDeviceId() would be unique, but apparently not.
Maybe the mac address?
I noticed that PS_EncryptSignDecryptVerifyAesCcm and one other needs the mac address as a parameter.
I thought that PS_GetDeviceId() would be unique, but apparently not.
Maybe the mac address?
I noticed that PS_EncryptSignDecryptVerifyAesCcm and one other needs the mac address as a parameter.
It's the default make tool that's already set up. I tried making one myself but that didn't work either.
It's ok though, I'm not too fussed because I've found it works fine via cmd. Maybe PN doesn't pick up my path variables? More likely I just don't understand
- Joined
- Nov 24, 2014
- Messages
- 3,162
- Trophies
- 2
- Age
- 29
- Location
- Bologna
- Website
- rinnegatamante.it
- XP
- 4,857
- Country
Why you use apt service to go back Homebrew Menu?
You just need to close all used services and do a return in main function. ( Something like this: https://github.com/Rinnegatamante/lpp-3ds/blob/master/source/main.cpp )
I'm trying to "make install" the latest build of ctrulib since my version is almost 11 months old now.
I get this error message:
I get this error message:
Code:
/opt/devkitpro/ctrulib/libctru/source/sdmc_dev.c:95:3: warning: excess elements in struct initializer
/opt/devkitpro/ctrulib/libctru/source/sdmc_dev.c:95:3: warning: (near initialization for 'sdmc_devoptab')
make[1]: *** [sdmc_dev.o] Error 1
make: *** [build] Error 2
- Joined
- Nov 24, 2014
- Messages
- 3,162
- Trophies
- 2
- Age
- 29
- Location
- Bologna
- Website
- rinnegatamante.it
- XP
- 4,857
- Country
- Joined
- Feb 10, 2009
- Messages
- 5,484
- Trophies
- 2
- Location
- Sacramento, California
- Website
- lazerlight.x10.mx
- XP
- 5,491
- Country
I had a similar problem a couple of days ago when putting my stuff on my laptop. Run the automatic installer again, and then try compiling the ctrulib source.
- Joined
- Feb 10, 2009
- Messages
- 5,484
- Trophies
- 2
- Location
- Sacramento, California
- Website
- lazerlight.x10.mx
- XP
- 5,491
- Country
Well, I "may" have a solution to my problem and still maintain the 1024x1024 texture to output to. Guess I should let you all know the purpose for this whole thing so people will understand what I'm trying to do, get insight and possible solutions to improving it.
Mode 7.
I'm testing ways to improve Mode 7 with blargSNES under hardware rendering. Currently with the WIP version I pushed to gitHub long ago, the Mode 7 process was handled much the same way tile scanning was done for all other backgrounds, but could result in being CPU-heavy depending on the scale, rotation, and mid-frame changes (for perspective Mode 7) of the layer, to the point where it would be better to run under software for various scenarios.
So, my idea was to simply render the entire Mode 7 layer to its own texture (which is a static 1024x1024 pixel area), and then use that texture and simply plot that down. That would make the process more static than dynamic, and would take into account scenarios where even if the layer is zoomed out so much that it's wrapping, the use of a texture would allow that. Of course though, I mentioned earlier how rendering to that size of a texture is slow. The latest solution that I thought up the other night would just use the current method that's required to render to a 1024x1024 texture in the first place. Render smaller sections, but in this case, don't render all sections in the particular frame. Perhaps just half or a quarter, depending on if that section needs to be updated. The section that don't get updates will just show what's been retained from their last update, not reliant on color, VRAM, and layer changes. I'd imagine that most people would not notice it except for when the Mode 7 is initially used, as it would likely be blank, but that's based on the situation. Thinking that changes to the color palette would flag all 4 sections to need updating (but not all updated in the same frame), changes to tile cels will flag only those sections that specific tile cel is used in, and then changes to individual tiles on the layer will only flag the one section that change was made in.
So that's where I am right now. I would, however, request anything that would help with the actual rendering process to the large texture, like whatever sort of settings for the GPU would grant the fastest processing, as I'm simply rendering a pre-made list (that has polygon coordinates already set, like <0,0>, <8,0>, <24,16>, etc) that only changes with where the "tiles" are taken from the source texture (that has 256 8x8 pixel tiles). Figured no culling, no depth processing, etc would help, but I may be missing some other things.
Mode 7.
I'm testing ways to improve Mode 7 with blargSNES under hardware rendering. Currently with the WIP version I pushed to gitHub long ago, the Mode 7 process was handled much the same way tile scanning was done for all other backgrounds, but could result in being CPU-heavy depending on the scale, rotation, and mid-frame changes (for perspective Mode 7) of the layer, to the point where it would be better to run under software for various scenarios.
So, my idea was to simply render the entire Mode 7 layer to its own texture (which is a static 1024x1024 pixel area), and then use that texture and simply plot that down. That would make the process more static than dynamic, and would take into account scenarios where even if the layer is zoomed out so much that it's wrapping, the use of a texture would allow that. Of course though, I mentioned earlier how rendering to that size of a texture is slow. The latest solution that I thought up the other night would just use the current method that's required to render to a 1024x1024 texture in the first place. Render smaller sections, but in this case, don't render all sections in the particular frame. Perhaps just half or a quarter, depending on if that section needs to be updated. The section that don't get updates will just show what's been retained from their last update, not reliant on color, VRAM, and layer changes. I'd imagine that most people would not notice it except for when the Mode 7 is initially used, as it would likely be blank, but that's based on the situation. Thinking that changes to the color palette would flag all 4 sections to need updating (but not all updated in the same frame), changes to tile cels will flag only those sections that specific tile cel is used in, and then changes to individual tiles on the layer will only flag the one section that change was made in.
So that's where I am right now. I would, however, request anything that would help with the actual rendering process to the large texture, like whatever sort of settings for the GPU would grant the fastest processing, as I'm simply rendering a pre-made list (that has polygon coordinates already set, like <0,0>, <8,0>, <24,16>, etc) that only changes with where the "tiles" are taken from the source texture (that has 256 8x8 pixel tiles). Figured no culling, no depth processing, etc would help, but I may be missing some other things.
