u/allanrps

Im having an issue with my og gba where the device will boot the game with the green led lit, but after a short period of time the device will fizzle out. Like it will half shut off, where the display stops updating, becomes faded and has lines in it, as if the device was shut off but only half the effect. Sometimes the display will slowly fade over the course of 30 sec or so before the device becomes unresponsive. Upon rebooting the device, it will function for progressively shorter periods of time before simply getting a blank screen. The green power led remains on. I have opened the device and noticed nothing obviously faulty, other than some slight corrosion on the battery terminal, which I cleaned up a bit to no effect.

I am in an underdeveloped country, and while the batteries I am using are name brand, they are definitely not quality. I don't know if this is the issue, but the device was working with these batteries before and I have tried multiple sets now and get the same behavior.

Any Ideas?

Basically I don't have access to a pc and I want to add some games to the goomba emulator. I tried running the frontend in winalator but no dice. Does anyone know how to proporly format entries to add games directly in a hex editor?

I am getting a weird issue where a game boots but its like the up button is being held down, it just rapidly scrolls through the menu. The file is tested on PC and works. The game is Ring^-27, installed "Custom", using Compatibility modes, running on a Fold 6. I've changed all the "controller" settings and got nothing

After getting more player feedback and sinking more hours into playing it, I decided the game was too hard. On Loop 2 you had to have perfect routing even at low ranks otherwise the screen would be filled with bullets. So I slightly lowered the firerate of most enemies. Loop 2 is still hard as hell, but should be a bit more "fair" as they say. Just wanted to update those that have been playing so that they can re-patch.

Also I have heard all the cries for improved music, and while I must be honest and say the likelihood of that materializing is low, I am thinking about it...

On a side note, it is hard to get an accurate read of difficulty you are curled over your laptop reading machine code all day lol.

DOWNLOAD HERE

[ Removed by Reddit on account of violating the content policy. ]

From a gameplay perspective; I know the technology was something special at the time, being one of the first games to have compelling pseudo 3d visuals. The game itself, however, just seems like there's​ nothing to it. Just fly in circles and try not to hit trees. It's basically a less cool version of gyrus where the player sprite is covering all the action. Seriously, Harrier makes a way better door than a window.

In today's day and age, when its graphical presentation isn't gonna carry it, is Space Harrier worth playing?

I'm working on optimizing hit detection on a prexisting engine, and I'm looking for fresh ideas. This is for the gba, so that means a 32bit armv7 processor running mostly 16bit code, with a 32bit data bus for internal ram and 16bit bus for rom and external ram.

At the outset I was thinking to just do the basics ie. clean up the code, trim unnecessary instructions, make sure the pipeline is organized/conditional branching is limited, and maybe rework some arithmetic if I saw opportunity for it. After looking through the code, I see that that won't get me very far. I haven't totally deciphered whats going on in this program yet but it seems I am facing two distinct challenges.

The bottleneck with the terrain collision detection is the fact that it realies heavily on multiplication against a sampled sine wave retrieved from rom. So it calculates fraction values by getting an offset value from this wave form, multiplying with the object coordinates, and shifting right. Some distinct factors are that this only uses object coordinates, no hitbox data, and it references a crude tile map of collidable terrain. I believe that the program is clalculating inter-tile proximity against the collision map, because collision with terrain is rather nuanced in this game.

Are there any general tricks that others employ to optimize a multiplication heavy flow like this? Maybe there is another way to go about this without totally redrawing all the collision maps? Maybe I can implement a seperate collision routine used only by bullets which is cruder and uses less multiplication. Maybe I can even check the object count and use this routine only after a certain threshold is reached.

The hitbox detection routine is rather straightforward, and it seems like it is being throttled mostly by lots of memory access and conditional branching. I think the main issue is that all the object data is stored in external ram which only has a 16bit bus, so the program is constantly fetching 32bit values and shifting them to 16bit values in different registers. In this case, wouldn't it be faster to just fetch each halfword seperately? How much performance is to be gained from switching to 32bit mode to process this data?

It seems like most of the operations could be rolled into compound instructions, but I would have to learn how to construct full width arm instructions (yeah I know the manual exists and I will use it). It would also make sense to load this whole routine into iwram (32bit bus) and keep it there, since it's getting called multiple times per frame for every on screen object. But if the issue here is due to wait states from memory access, would that really help much? It should help with wait states incurred from pipe line disruptions because of all the conditinal branching, as fetching the next instruction from iwram would be faster than from rom. I see another potential benefit being the ability to ldmia into high registers and perform operations on those values immediatly, allowing me to eliminate instructions. But again, 16bit data bus! Maybe I'd get just as far sticking with thumb code in iwram and using half word loads.

Anyways, my apologise to those to whom this makes absolutely no sense, inexperienced and experienced alike. It was quite helpful to write this all out actually, and I feel as though I have a plan forming. I would appreciate any thoughts or insights to help me dial down what direction to go in, as we know how arduous it is to move around millions of pointers if I have to change my approach down the line.

Has anybody been able to get libgdiplus working with mono? Im trying to compile libgdi plus but running into this error

ld.lld: error: undefined symbol: pango_fc_font_map_set_config

I have all available pango packages installed. I am also using mono from the repositories, and when trying to build mono-android I am getting error

processes.c:1651:12: error: call to
      undeclared function 'makedev'; ISO C99 and later do not
      support implicit function declarations

Any ideas?

I'm wanting to do some hacking on this game to make it more challenging. does anybody have some saves or save states at various points of progress in the game? best case scenario would be before each boss and mid way through each level

I've found plenty of info on box64 and the like, but what do I do if the excecutable is already compiled for the device archiecture, arm64? I couldn't find any built of wine or similar for this.

Any devs out there know what significance this constant has? I was looking at implementing a soft reset button combo as a rom hack, and upon analyzing the code related to program states/sequencing in my reference rom I found this number being referenced. I was surprised to find the same number present in the rom I wanted to hack. My first thought is maybe it has to do with setting bits for an interrupt or something like that. It gets written to memory from rom, incremented, and restored to its original value from rom.

Any devs out there know what significance this constant has? I was looking at implementing a soft reset button combo as a rom hack, and upon analyzing the code related to program states/sequencing in my reference rom I found this number being referenced. I was surprised to find the same number present in the rom I wanted to hack. My first thought is maybe it has to do with setting bits for an interrupt or something like that. It gets written to memory from rom, incremented, and restored to its original value from rom.

Its not present in the repositories, but invoking qmake says that it should be. I swear I had installed it from the repositories in a previous build. Any ideas?