Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (710)
Games in Android Showcase (212)
games submitted by our members
Games in WIP (784)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  AGB Programming  (Read 756 times)
0 Members and 1 Guest are viewing this topic.
Offline Hydroque

JGO Coder


Medals: 25
Exp: 5 years


I'm always inspiring a good time.


« Posted 2016-10-12 10:39:43 »

So recently I have been doing some tinkering with one of the things that made my middleschool less stressful. My gameboy advance. By tinkering, I mean actually programming it. Surprisingly enough, I have a load of articles and documentation on each of the features that the AGB has. Of course, my OpenGL experience had 99% of my problems learning hidden away and 1k google searches later actually finding the solution, but that is digressing.

After seeing how good the AGB is at actually accomplishing its game-related tasks, looking to program games on the computer seem like a real laugh. The AGB has 96kib of video memory (240x160 native res), uses color lookup palletes, and a whopping 16.78MHz processor. Fun fact is it is coded in ASM, C, (not recommended cuz overkill) and C++. One of the questions that I want to bring up is how come AGB can make fantastic games, such as pokemon, but the modern games we have today, which are 2D, have performance issues? (Keep in mind the AGB isn't the most powerful thing)

By the last paragraph, I want to ask, how far have we abstracted? Along with this, in terms of shading, do we really need all the power we have today to represent our stuff?

An example of the last sentence is at 0x6000000 our VRAM stops until VRAM + 96kib. You draw directly into this field, which can be double buffered, instead of having OpenGL iterate through every pixel.

The goal for this post was to see what the community thinks about graphics performance and how much we abstract things. Anything related is great Smiley

You think I haven't been monitoring the chat? http://pastebin.java-gaming.org/c47d35366491fHere is a compilation <3
Offline Archive
« Reply #1 - Posted 2016-10-12 17:39:31 »

First off, I'd like to say I have no experience or professional insight on this. However, games with performance issues are typically made by indie devs and people still learning how to write a good program. AAA games with performance issues on the other hand are either pushing the limitations of the modern GPU or they rushed the game so that they can meet deadlines. Understand that the games back then were made on hardware MADE for gaming ONLY. It would be like the Xbox team at microsoft making a game for the xbox. They know the platform inside out and they can optimize everything to make it as efficient as possible.
Most people new to modern game programming take the performance for granted and usually never learn to optimize properly.

Offline KevinWorkman

« JGO Plugged Duke »


Medals: 245
Projects: 12
Exp: 12 years


klaatu barada nikto


« Reply #2 - Posted 2016-10-12 17:50:40 »

One of the questions that I want to bring up is how come AGB can make fantastic games, such as pokemon, but the modern games we have today, which are 2D, have performance issues? (Keep in mind the AGB isn't the most powerful thing)

Poorly programmed games (or, games that chose to prioritize other stuff) have performance issues. Well-programmed games (or, games that prioritized performance) have better performance.

You seem to be saying that every game for the GBA outperforms every modern game, which is simply not true. There were plenty of poorly written games for the GBA, and there are plenty of well-written games today. That plus modern hardware means that we're doing stuff today that would be physically impossible on the GBA.

It's a bit like the people who say that today's music is terrible compared to music from [insert decade here]. A lot of that is selection bias, because you don't remember the 95% of songs that were terrible from your favorite decade, and you're ignoring the good songs from today. You're comparing one of the most famous games of all time to games that you see on Steam, which isn't exactly an apples to apples comparison.

By the last paragraph, I want to ask, how far have we abstracted? Along with this, in terms of shading, do we really need all the power we have today to represent our stuff?

Sure, one of the "problems" is that we have so much more available at our fingertips. Want a particle system in your game? That's a one-liner. Want physics? Here's Box2D. Want lighting? Here you go. So it can be easy for developers to shove a bunch of stuff that they might not need into a game, without worrying too much about performance or the hardware they're running on. They might design it for their $5,000 hardcore gaming PC, and you'll have issues running it on your 5-year-old Android phone.

But I would argue that's a good thing for the most part. As a developer, I don't want to have to worry about which hardware I'm running on, and I don't care about all the hardware-specific hacks that I could take advantage of if I limited myself like that. I also don't want to reinvent the wheel every time I sit down at the computer, so all these libraries and frameworks are great for me.

That being said, there is a big community around developing games for retro systems. It sounds like you've taken an interest in that, and that's great. Have fun with it. But it's certainly not as simple as saying that the GBA is better at games than modern hardware and software.

HappyCoding.io - Coding Tutorials!
Happy Coding forum - Come say hello!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline unlight
« Reply #3 - Posted 2016-10-13 11:26:13 »

I think it is largely to do with the fact that you are programming quite close to the machine with a GBA. It requires a lot of direct, low-level hardware access; more akin to writing code for a micro-controller than a modern computer. This process is extremely time-consuming and a lot of game-devs probably don't care to go that low-level if the don't need to. Modern game engines that are all about simplifying the process of game dev typically offer a high-level programming language that is compiled to run on a range of different computer hardware configurations. The trade off is that the programs will not run as efficiently as (well-written) assembly code created for one specific piece of hardware.
Offline Hydroque

JGO Coder


Medals: 25
Exp: 5 years


I'm always inspiring a good time.


« Reply #4 - Posted 2016-10-14 12:15:22 »

I think it is largely to do with the fact that you are programming quite close to the machine with a GBA. It requires a lot of direct, low-level hardware access; more akin to writing code for a micro-controller than a modern computer. This process is extremely time-consuming and a lot of game-devs probably don't care to go that low-level if the don't need to. Modern game engines that are all about simplifying the process of game dev typically offer a high-level programming language that is compiled to run on a range of different computer hardware configurations. The trade off is that the programs will not run as efficiently as (well-written) assembly code created for one specific piece of hardware.

I like your approach in not jumping to saying I am claiming the GBA is not better than any computer. While working with the hardware level gameboy is what is being done, there are in fact libraries out there that sit on top of the different hardware features that the gameboy has. As well as writing directly to ram.

In my mind I keep thinking, "gee we have all these libraries utilizing other libraries utilizing other libraries" it gets me thinking that low level is good. As for time sake, people have their reasons. However, even in the days of computers which small amounts of ram, people continued to develop these games. It seems to me that over the years of this development, things change, get fixed, shift around, and ultimately you have this big bundle of old methodology thrown askew everywhere. (Intermediate mode, opengl, for example) Developers shift their access away to the low level things such as registers and pay more attention to the higher level of things.

If I go out and adopt a library for the AGB system, it is my duty to learn the background. However, this is not suseptible to what I have been talking about in the last paragraph with changes, if it were to be updated with flashy new stuff you start the tree of extending the newly extended library. I guess I will call it libraryception. If you are familiar with writing OpenGL render code, etc there is always the hard code that must be written down each time.

Back on the micro-controller verse modern computer talk, with what other people said, the GBA was designed for gaming. One of the biggest ummms.... is running pokemon using OpenGL or software rendering will NEVER be as little resource/little power used as the GBA can run it. This opinion claim comes from the idea that the developer handles even the ram and bits are crunched whereas the computer's gfx card with just draw two triangles into a quad.

You think I haven't been monitoring the chat? http://pastebin.java-gaming.org/c47d35366491fHere is a compilation <3
Pages: [1]
  ignore  |  Print  
 
 

 
numerical (74 views)
2017-02-21 07:32:16

numerical (75 views)
2017-02-21 07:31:46

theagentd (180 views)
2017-02-18 13:42:33

theagentd (182 views)
2017-02-18 13:35:16

h.pernpeintner (1345 views)
2017-01-24 22:39:11

h.pernpeintner (1333 views)
2017-01-24 22:38:32

Galdo (1894 views)
2017-01-12 13:44:09

Archive (1983 views)
2017-01-02 05:31:41

0AndrewShepherd0 (2519 views)
2016-12-16 03:58:39

0AndrewShepherd0 (2310 views)
2016-12-15 21:50:57
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!