#178360 - Edward_Stryfe - Sat Apr 04, 2015 8:33 pm
Hello, my name is Edward, I'm 14 a highschool freshman and courently work in the range of website development via HTML, CSS, and a Hint of PHP. Recently however I came across a website called Loirak featuring a tutorial on how to compile GBA and GB roms from C++. Now I haven't begun programming with C++ and am in the middle of learning php; however I have a by example book about 700 pages long on C++ ver. 4.0. I'm most definitely into creating high quality freeware, and at the moment can't do anything more than distribute it via websites that i'd have to develop. So I'm very interested into joining the GB/A game programming community, specifically because it's an OS free situation. Don't have to do special things to compile and etc for linux, windows, android, and apple. So I am especially new to the GB/A programming community and would love if someone at the very least could maybe give me a difficulty comparison between, maybe javascript, php, or html to C++. However despite all this I feel as of though I'm late and that this is dead forum, but I saw a few 2015 posts so I'm hopeful there's someone who would assist me in the begining of my venture.
#178362 - elhobbs - Sun Apr 05, 2015 5:54 pm
Homebre development can be a bit discouraging for someone learning c/c++. The lack of a graphical debugger is probably the largest obstacle. If you are trying to learn the basics then a graphical debugger is immensely helpful. Then there is the low level nature of the resources. You need to deal with hardware directly - registers, polling, interrupts, memory regions with special write restrictions. On top of that the processor is really slow and there is only a tiny bit of memory compared to a modern pc. It is not impossible, but it is certainly more difficult than learning on windows or Linux and then coming back to the gba. If that didn't discourage you then I would recommend installing devkitarm from the devkitarm website and try compiling the examples. Then try modify the examples.
#178363 - Edward_Stryfe - Mon Apr 06, 2015 9:49 pm
First I would love to thank you believe me I'm not discouraged at all by it the mere fact that someone replied has me ecstatic about this whole thing. Now you said something about graphical front end or something. I'm assuming that is the devkitarm you mentioned and if so thank you, if not what would be a good free one. Also a note I think is important, is that I have arleady installed a c/++ to gba compiler known as devkitadv. The software is functional, but the tutorial was poorly written confusing and generally uninformative, I'm sure I can find better ones on this forum though. Anothing note is that I have not begun programming in windows, or linux however despise windows and plan on creating a linux distrobution in the future. While that is true I have a general hatred for most of the media out there on the market for ridiculous prices[Extreme Catholic & Conspiracy Theorist{Also notest that your post was your 666th}]. So I want to in the very easiest way possible make multi-platform software but it's way easier to create a single rom for all formats as opposed to learning all of them and re-programming the same game that many times. Once again I want to thank you for doing as much as responding and if you could just clarify what that graphical front or whatever that stuff was you mentioned was, and the purpose of the devkitarm software that would be awesome!
#178364 - DekuTree64 - Tue Apr 07, 2015 12:11 am
DevKitAdv is really old. Though GBA can be programmed very directly, so there's hardly any need for an SDK anyway. But the GCC compiler has been improved a lot since then, so newer versions should produce better optimized machine code.
DevKitARM is the successor to DevKitAdv, and is also free/open source. DevKitARM is part of a larger collection called DevKitPro, which has tools for GBA, DS, Gamecube, Wii, and other systems. I don't think you need to install the whole DevKitPro if GBA is all you're doing though.
DevKitARM is just a collection of command line tools. No graphical interface. But you can use a separate IDE for your code editing, and set it up to run the devkit compiler, and output error messages in the IDE so it's all user-friendly. CodeBlocks is a pretty good open source IDE.
But you still won't be able to do source level debugging (stepping through code one line at a time, or tracing back through the call stack and looking at variable values to find the cause of a crash). When running on GBA hardware, all you have is the screen, so debugging is limited to whatever your game draws to the screen.
There is an emulator called no$gba made by a guy named Martin Korth, which can do source level debugging. It used to be that you had to pay quite a bit for the debugger version, but I think he may have made it free a while back. I've never actually used it though, so I don't know what's involved in getting it to work.
Emulators (no$ and VisualBoyAdvance and probably others) also have some basic debugging tools like memory viewers and disassembly.
I'm actually not sure whether it would be easier to learn C++ on PC or GBA first. PC has better debugging, but for small learning programs, that's really not such a big issue. And the nature of GBA programming makes some things more obvious. Particularly pointers. On GBA, all the memory of the system is pre-defined at certain addresses, so you can just typecast an exact memory address into a pointer type, and use it to write directly to that address. Much more clear than on PC, where you call malloc or new to request some memory, but don't know or care what the physical address is. I love working the hardware directly, rather than having to go through OS and API calls to do anything.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#178365 - Edward_Stryfe - Tue Apr 07, 2015 2:38 am
Thank you I will look into this devkitarm project it sounds very usefull. While I am only going to START with gb/a programming I would definately be will to code in other consoles as well[assuming I get a team to join me]. Now source level debugging I must say would be like the best thing in the bloody world I mean literally but if it hasn't been released for free I'm sure somebody has made freeware version. Thank you so much for the imput. Also a note for any future posts, while new to programming I am very knowldgable of the world of emulation and roms. Before I used roms for what this community would consider shady and illegal activity, such as downloading and running unliscened bootleg roms for a lot of consoles, however though that was do to a lack of funding and a extremely large amout of free time. Though now I have more money avaible to invest in games giving me no need to download bootleg games, that and after reading thousands of articles about the crack-down on piracy I figured I'd take a different aproach to the event by creating the best freeware I can, while this isn't very aparent at the given time. I'm in the middle of scripting tv series movies and websites as well as tutorials and now games. Thanks to this community I'm super happy about it too knowing that I'm not the only person interested in making games for a system this outdated. Thanks in advanced for all the help you guys give me through this forum. (Extra: DekuTree64 lulziest username yet thanks for being awesome XD)
#178410 - pitcrawler - Fri May 01, 2015 3:19 pm
| DekuTree64 wrote: |
| Emulators (no$ and VisualBoyAdvance and probably others) also have some basic debugging tools like memory viewers and disassembly. |
Visual Boy Advance actually has excellent debugging features.
| https://github.com/x3ro/VisualBoyAdvance wrote: |
GDB support
-----------
VisualBoyAdvance now provides GDB remote debugging support. This gives
developers the full power of GDB to debug GBA applications.
In order to use this, you will need a cross-compiled GDB for either the arm-elf
or arm-thumb-elf target (used for the --target= option of GDB configure
script).
You can also use GDB frontends like DDD, CodeMedic, etc... or even GDB/Insight
for GUI debugger (if using anything other than GDB/Insight, please make sure
to point to the right GDB executable).
...
Built-in debugger enhancements
------------------------------
The built-in debugger has the following enhancements (need debug enabled ELF
file):
- ELF file support: both multiple and regular. Please report any messages or
problems reading ELF files. C++ classes and some miscellaneous features are
not supported yet. Also, method names may be mangled in C++ code.
- break command: add a breakpoint on a function, line number of file:line
number
- locals command: print the local variables on the current function
- print command: prints the value of a given expression. Valid expression
include *this, ptr->member, var.member, array[0], sizeof(expression), etc...
- symbols command: list information known about a symbol (or symbols that start
with the given name)
- radix command: sets the output radix to eithe decimal, octal or hex.
- file and line number when stopped: the debugger will show the file and line
number (if available) for the current address
- fixes to some breakpoint handling problems
- fixes to break on write function |
Once you get everything set up, these features make things a million times easier for the inexperienced GBA programmer. You can do things like step through the program line by line and see how the screen reacts on the emulator.