+- Dolphin, the GameCube and Wii emulator - Forums (https://forums.dolphin-emu.org)
+-- Forum: Offtopic (https://forums.dolphin-emu.org/Forum-offtopic)
+--- Forum: Delfino Plaza (https://forums.dolphin-emu.org/Forum-delfino-plaza)
+--- Thread: Programming Discussion Thread (/Thread-programming-discussion-thread)
RE: Programming Discussion Thread - Shonumi - 07-16-2016
(07-16-2016, 02:10 AM)DacoTaco Wrote: just wondering how much these are different?
cause i have a link cable that has the GB© end and GBA connector at both ends of the cable and i can use it just fine with the gameboy player & a gameboy. so somehow they are compatible ?
It's nothing to do with the link cable itself (when talking about emulation). The GBA uses different registers and methods of transferring bytes. The GBA can communicate with GBs with the right cable, but the GBA boots into GBC mode and uses the older serial transfer method. The newer method is far faster than the GB can handle though, so that's why you can't have GB games.communicate with GBA games.
RE: Programming Discussion Thread - DacoTaco - 07-17-2016
(07-16-2016, 02:54 AM)Shonumi Wrote: It's nothing to do with the link cable itself (when talking about emulation). The GBA uses different registers and methods of transferring bytes. The GBA can communicate with GBs with the right cable, but the GBA boots into GBC mode and uses the older serial transfer method. The newer method is far faster than the GB can handle though, so that's why you can't have GB games.communicate with GBA games.
aight, thank you.
thats alot better then just hearing "they are different. period"
so if i understand correctly its more of a "in gba mode, the internal hardware & protocol is different and faster"
RE: Programming Discussion Thread - Shonumi - 07-18-2016
(07-17-2016, 05:50 PM)DacoTaco Wrote: thats alot better then just hearing "they are different. period"
so if i understand correctly its more of a "in gba mode, the internal hardware & protocol is different and faster"
Yup. On the GB/GBC, the method of serial transfer is kind of weird by modern standards. Each Game Boy has a single byte in memory that will be transferred (called SB, probably for Serial Byte). Each GB basically swaps their respective bytes, 1 bit at a time. It does this 8 times at a certain rate, then signals an interrupt on both Game Boys. Transferring the data is supposed to happen simultaneously (practically instantly, with a few cycles of delay I assume), but the GB/GBC could only transfer at a few selectable rates. The original GB could only do 1KB/s, but the GBC could do 1, 2, 32, or 64KB/s. In reality, it's pretty hard to take full advantage of the 64KB/s mode because under the most ideal circumstances, the CPU only has a measly 64 cycles to process one byte and transfer another (1/4 of that time is spent just getting the hardware to acknowledge the serial transfer interrupt). It's doable in assembly though.
On the GBA, there are only 2 speeds, 32KB/s is the lowest (incompatible with the original GB, and technically incompatible with the GBC on slower speeds) and 128KB/s, although reportedly the 32KB/s is the most stable. I have not investigated too much into GBA multiplayer, but from what I understand, the key thing that prevented GBA games from talking to GB/GBC games was differences in voltages for their cartridges (and other components?). The GBA actually had a physical switch that is tripped when sticking in GB/GBC games that forces it to use 5V, but normal GBA games use 3.3V. I gather that this affects the serial transfers as well.
RE: Programming Discussion Thread - Shonumi - 08-14-2016
Been pretty busy on GBE+. Link Cable is working like a charm, as I said earlier. The GBC's IR port in partially emulated; it only works for Pokemon Mystery Gifts since everything else seems broken. The GB Printer is supported now too. Last but not least, I finally got around to implementing post-processing shaders. GBE+ now requires OpenGL 3.3+ for hardware acceleration. I only have 1 post-processing shader that does anything interesting, a simple sepia filter, but hopefully I can get more done, especially ones involved with scaling filters.
Spoiler: (Show Spoiler)
![[Image: t5gRJ6Z.png]](http://i.imgur.com/t5gRJ6Z.png)
RE: Programming Discussion Thread - KHRZ - 09-12-2016
Anyone here been doing any procedural generation? I'm planning to make random maps for an RTS, where you place trees/various stuff spread around (e.g. enemy camps/loot sites). So far I am using perlin noise for the trees, but need to make sort of a path system between all the stuff, where trees don't block stuff inside forest. First step is to place them somewhat randomly and spread (e.g. not too close to each others or the player's base). Civilization is the closest example I can think of. The simplest way I can think of is just place the stuff randomly, then check if it's close to something else, then try again. But prone to infinite loops if you place a lot of stuff and they get placed in a bad way.
RE: Programming Discussion Thread - teh_speleegn_polease - 09-12-2016
I've never done anything of the kind, but if it's stuff you have a lot of (trees?), then maybe place randomly, then check if anything is in the way, and delete those things to clear the path? You'd need a pathing algorithm that can determine which trees need to be deleted (all of the ones I know, which is to say one or two, only check for a path an abandon with no data returned if one cannot be found) and you could maybe have a lower threshold that could be used to re-generate more stuff if your first generation is so bad a huge amount gets deleted. Or even let it go and have it be a quirk of the generation - every now and then you'd get unusually sparsely populated maps, which might add to the flavour more than anything.
I'm not actually sure such a path algorithm exists in the first place, though.
RE: Programming Discussion Thread - KHRZ - 09-25-2016
My idea is that after you place the loot locations/bases, they each have a radius without trees, and I use the smallest spanning graph or something for the paths. (and maybe add some more paths if there's too few). Then each tile will well measure the distance to the closest path/base, and I can reduce the amount of trees based on the distance. Now possibly the biggest concern is that the distribution of stuff will suck, I am thinking they will also have a radius where they decrease the chance of stuff spawning nearby, and with 2 things spawning close together, this would make for 0 chance of more spawning in a lot of the near area. Even if it's not rocket science, I was wondering though if there was already some famous ways of doing it...
RE: Programming Discussion Thread - Shonumi - 02-06-2018
Resurrecting this old thread. Been working on my software renderer for NDS 3D graphics. Finally getting somewhere.
![[Image: XcZghdf.png]](https://i.imgur.com/XcZghdf.png)
Yeah, it's just the lines, and nothing fancy like vertex colors or textures. But it's a start. The plan is to work on HD rendering (both software and hardware versions) simultaneously, so basically my process will be:
1) Do stuff correctly at 1x in SW mode
2) Do stuff correctly at 1x in HW mode
3) Do stuff correctly at 2x and above in SW mode
4) Do stuff correctly at 2x and above in HW mode
So every time I implement a new feature, I'll take the time to make sure all 4 scenarios work. I figure this will help make HD stuff a reality if I aim build that functionality right from the start, as opposed to adding it on later.
RE: Programming Discussion Thread - DacoTaco - 02-07-2018
(07-18-2016, 01:08 AM)Shonumi Wrote: Yup. On the GB/GBC, the method of serial transfer is kind of weird by modern standards. Each Game Boy has a single byte in memory that will be transferred (called SB, probably for Serial Byte). Each GB basically swaps their respective bytes, 1 bit at a time. It does this 8 times at a certain rate, then signals an interrupt on both Game Boys. Transferring the data is supposed to happen simultaneously (practically instantly, with a few cycles of delay I assume), but the GB/GBC could only transfer at a few selectable rates. The original GB could only do 1KB/s, but the GBC could do 1, 2, 32, or 64KB/s. In reality, it's pretty hard to take full advantage of the 64KB/s mode because under the most ideal circumstances, the CPU only has a measly 64 cycles to process one byte and transfer another (1/4 of that time is spent just getting the hardware to acknowledge the serial transfer interrupt). It's doable in assembly though.its funny how 2 years later im implementing all this in my AVR code to make my GBC/GBA dumper. im making my jump to gba mode. im stuck on the switch since the gba connector i got was damaged and didn't have the switch
On the GBA, there are only 2 speeds, 32KB/s is the lowest (incompatible with the original GB, and technically incompatible with the GBC on slower speeds) and 128KB/s, although reportedly the 32KB/s is the most stable. I have not investigated too much into GBA multiplayer, but from what I understand, the key thing that prevented GBA games from talking to GB/GBC games was differences in voltages for their cartridges (and other components?). The GBA actually had a physical switch that is tripped when sticking in GB/GBC games that forces it to use 5V, but normal GBA games use 3.3V. I gather that this affects the serial transfers as well.
RE: Programming Discussion Thread - KHRZ - 02-19-2018
Rant time. So apparently the genius guys at Unity has decided that any vector with values <= 0.1 should just be rounded off to 0 in their ToString method (despite showing like 5 decimal places usually). So I keep thinking my vectors are zero while I am debugging, and got rekt for the second time. I have seen some shit in my life but this is probably the most retarded thing I've seen put out by a big company.