This kind of homebrew usually requires a GBAMP v2 or similar card (gba slot) in order to save the data... This exact download has been tested, run, and succesfully controls World of Warcraft. This was done using the R4v1 (bugged spring version with MicroSD) and a GBAMPv2 (half red, half white CF GBA cart). Without the *.gba file in the root directory (meaning D:\ or E:\ etc) this program wont find the file and cant pull memory from it. Check your hardward then report back. Good luck. Its a bit buggy for WoW and theres a huge lack of controls, but it still works none-the less. If i were to name the problems, 1 would be that it almost seams like it converts to 256 and THEN shrinks... converting takes a fraction more time to process... who knows, might not... Also, I understand the controls are designed fore desktop use and not gaming, but for most applications, this homebrew lacks that certain bit of customization. Thirdly, i believe the touch screen can be improvised. Personally, id like a better scroll function, and the option to use a full-screen based touchpad or a mouse-pad based touchpad. To describe this more, the Full-screen method uses a touchpad to click anywhere on the ENTIRE screen converted to 256x192 pixels (ds screen size). A mouse-pad method uses a area click method.it uses the place touched down as a centerpoint, and the new x and y values as movement. Theres also a bug in almost every homebrew ive faced when using the orignal DS and almost any flash card. This bug is found on touch.release methods where the new x/y is close to 180x230 and sometimes 180x20 ... this can be patched by a simple code line checking for last known movement coordinates before a touch.release and the release coordinates and checking the distance. Then add a maximum change distance which will cut out that bug at LEAST 80% of the time. Using a mix c++ code, ill present it: lastX = touchX; //variables (coordinate)
lastY = touchY;
touch.Get(); // touch press command
touchX = touch.X; // touch.X is the returned value
touchY = touch.Y;
//If pen was released, and distance traveled (x or y) is greater than 15
if (touch.release() && ((abs(touchX-lastX) > 15) || (abs(touchY-lastY) > 15))) {
touchX = lastX; touchY = lastY; // reset values
}
//15 means that you can still move the pointer quickly, but it will cut down on accidental off-screen presses that aren't your fault I was also wondering if it were possible to use the PC to select certain areas to map to the DS zoom screen... or even a hidden DS screen found when swapping through screen-methods... So far i see Zoom on Top, Zoom on Bottom, Shared Zoom (top, bottom)... adding another shouldn't be too terribly bad right? The idea of this is to locate commonly pressed buttons to easily click. Areas that the user has to retrieve over and over, but doesn't need the zoom to sit there. Little complicated, but just more ideas thrown out there. That, or a customizable Touchscreen savepoints mapped to an ini file would be useful. make a button-based menu that has different mapped areas defined by the user. EX: #Script
# (startX,startY,endX,endY)Name,Type (LocX,LocY,Identifier,Var) Zoom = 1; Button = 2; Null = 0;
#Button Example
(001,001,010,010)StartMenu, Touch (190,2,0,0)
#Normal Zoom to Area Example
(001,011,010,020)Close, Zoom (1,240,1,4)
#Zoom to 1:1 scale Example
(011,011,020,020)Zoom Out, Zoom (1,1,1,1)
#KeyPress funciton
(011,011,020,020)Escape, Keypress (0,0,2,27)
#End Simple coding, Reads the button print locations, the text in the Button (not that i didnt actually scale the buttons) would read the type of action when its pressed, and what to do from there. Button Example would run a mouse-press event at 190x2 on the DS screen (translates to roughly the Start button's location) but wouldnt require zooming to that location. Normal Zoom to Area Example zooms to a 4:1 ration close to where the minimize-maximize-close buttons are found. the coordinates arent exact, but your embedded re-alignment should take care of mistakes like that. Zoom to 1:1 scale example would zoom completely out. This can sometimes be handy, more of just an example of what the code COULD do if implemented. KeyPress function would press a key that you constantly press. Not designed to replace the keyboard, more along the lines of making it easier to hit a constantly used button without having to hope you hit the button every time (make a few keys bigger) these buttons would come out looking like this: ________________________ [st][TR] .__[ZO] ________________________| Using a script like that would cut down on a lot of moving around, cut down on a NEED to use the zoom, and would make zooming to locations a fair bit easier and faster to do. Not to mention make this app actually practical ^.^