6Bit.net :: Forums - All Forums

Gekko Spring Cleaning

Sun, 21 Apr 2013 05:54:33 +0000

This is just a list of things of minor things that can be worked on now to keep Gekko development going. It's not really "cleaning" per-se, but here are some changes that I can add to master while I'm not working on hle-audio (which is getting along well actually). The purpose of this thread is purely motivational, I guess

~~Update parts of SDLJoypad for SDL 2.0~~
~~Prevent joystick input getting stuck in one direction~~
~~Rumble support for joysticks~~
Prevent all input from getting stuck in one direction
Allow joypad configuration via the Qt interface
Save joypad and keyboard input to XML
Add an in-app screenshot function
Find more developers interested in helping out?
Fix input on QT single window mode
Abstraction layer for disk I/O

If anyone has any other relatively small tasks, feel free to send them my way.

HLE Audio Progress Thread

Sat, 06 Apr 2013 04:25:46 +0000

Since I'm not on IRC nearly as often as I should be (only on the weekends really) I figured it'd be helpful to make a thread here detailing how it's going. Of course there's the blog, but that's more for a periodic look into what's being done rather than a back-and-forth technical discussion.

Just a recap, I'm starting off with Zelda ucodes first of all, specifically the Normal version (which covers games like Wind Waker, Twilight Princess, and Double Dash). The first thing to do is make sure the CPU and DSP can communicate with one another via their mail messages. Secondly, once all the mails are in order, the DSP needs to actually start gathering the audio data stored at the addresses passed by the CPU. Lastly, that audio data needs to be mixed and output to speakers. That's the broad plan in three steps. With all that work as a base, hopefully I'll be able to move onto the Light and DMA versions of the ucode, and then the big one, the AX ucode itself

As of this writing, I'm just about done sorting out the mail messages for the Normal version. ShizZy, as you suspected, I was not handling interrupts correctly. The interrupts generated from the Zelda ucode during its update were overriding one for the DSP's DMA. More specifically, as soon as an interrupt from the Zelda ucode's update was cleared, it would generate another one from its update function, so the DMA interrupt never even had a chance to get processed. Judging from the logs I had, the DMA interrupt was generated, but never cleared. Not so anymore.

I've gotten even more mail messages to show up (like 10 fold more, and yes, they're all correct ) by simply waiting for the DMA interrupt to clear until the Zelda ucode generates and interrupt during update. The mail messages stop much later now, probably because this was all a very crude mechanism I came up with on the way to work. I'll be studying interrupts more in depth, and hopefully the first stage will be sorted by next week.

Let There Be Light!

Thu, 21 Feb 2013 03:34:59 +0000

With EFB copies somewhat on hold, I've been working on lighting. Thus far, I've made some pretty quick progress... I've gotten the following somewhat working:

Normal decoding
Basic normal transformation
Material colors
Point lighting

That seems to be enough to get some interesting demo results and for a few games to show some promising things. Unfortunately, its also so incomplete that it breaks ALMOST everything. Nonetheless, some eye candy

Getting back to emulation

Fri, 15 Feb 2013 06:52:51 +0000

Yeah, after I made a few measly commits at the start of the year, I kinda began obsessing over my attempts to delve into Gameboy emulation. But having made significant progress on that end, it's time to seriously get back to Gekko. I've definitely been slacking; been part of the team for about a year, and my only major contributions thus far have been adding basic joystick support.

I know the rest of you are very understanding about these sorts of things (this is an all-volunteer OSS project, people have priorities outside of code, etc) but I greatly dislike not meeting my personal obligations. I made a commitment to the Gekko emulator, so I feel the need to start contributing in a more meaningful capacity. Hopefully my recent experience will prove useful; I've learned a lot about emulation, and I plan to continue that So, basically, expect me to be a lot more active than before.

Btw, Shizzy, I noticed that you have a blog on 6bit. I was wondering if I could have one as well? I'm a writer by trade (majored in English) and I've got an itch to write some pieces about emulation, various topics such as the technical stuff (programming components like the GC CPU/GPU/DSP), getting the most out of emulators, making your own "emu-console" from devices like the Raspberry Pi, explaining cool enhancements like Scale2x, etc. I could very well just start my own wordpress account, but why not have 6bit get the traffic?

EFB copies progress thread

Sat, 05 Jan 2013 18:33:10 +0000

This week I started working on emulating GameCube's EFB (embedded framebuffer) "copies", a mechanism games use achieve render-to-texture effects (among other things). The EFB is where the GPU draws the current frame, and the copy mechanism allows regions of it to be copied to RAM, where the game can then later use it as a texture. This is actually pretty challenging to emulate correctly... I'll probably go into the reasons later as I get deeper into this.

With my first attempt, I'm going to be doing a trick where the the EFB itself is never actually copied to RAM, instead it's just directly bound to an OpenGL texture. I'm then attempting to detect whether or not the game meant to use that EFB copy (instead of a "normal" texture) by where it's loading it from in RAM, and then just use that OpenGL texture that I previously created. This completely bypasses the step of actually writing the texture to RAM (and encoding it in the correct format). It's pretty much Dolphin's "efb2texture" hack. While it is by no means ideal (skipping that step means it is impossible to handle the case where the game directly modifies the EFB copy), it can probably be "good enough" for most games, its fast, and it's an easy thing to do just to get a proof of concept working.

So this is what I've been working on... Here is some progress thus far. In SSBM, EFB copies are used (for example) when your character goes off screen to create a little "icon" of your character showing the orientation of it (the game renders your character offscreen, copies the render to a texture, and shows that on a quad). I've gotten this "sort of" working, at least for the first frame or so. Then things fall apart, it seems that its losing track of the correct EFB copy result to use. See:

Tales of Symphonia :D

Thu, 01 Nov 2012 03:53:27 +0000

Now this game is starting to go ingame

It doesn't compile for Linux >_<

Wed, 31 Oct 2012 17:00:03 +0000

It fails in detecting GLFW >_<

Code:

butz@butz:~/gekko-gc-emu/build$ cmake ..

-- The C compiler identification is GNU 4.7.1

-- The CXX compiler identification is GNU 4.7.1

-- Check for working C compiler: /usr/bin/gcc

-- Check for working C compiler: /usr/bin/gcc -- works

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Check for working CXX compiler: /usr/bin/c++

-- Check for working CXX compiler: /usr/bin/c++ -- works

-- Detecting CXX compiler ABI info

-- Detecting CXX compiler ABI info - done

-- Looking for include file pthread.h

-- Looking for include file pthread.h - found

-- Looking for pthread_create

-- Looking for pthread_create - not found.

-- Looking for pthread_create in pthreads

-- Looking for pthread_create in pthreads - not found

-- Looking for pthread_create in pthread

-- Looking for pthread_create in pthread - found

-- Found Threads: TRUE  

-- Found SDL2: /usr/local/lib/libSDL2main.a;/usr/local/lib/libSDL2.so;-lpthread  

-- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so

-- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so - found

-- Looking for gethostbyname

-- Looking for gethostbyname - found

-- Looking for connect

-- Looking for connect - found

-- Looking for remove

-- Looking for remove - found

-- Looking for shmat

-- Looking for shmat - found

-- Looking for IceConnectionNumber in ICE

-- Looking for IceConnectionNumber in ICE - found

-- Found X11: /usr/lib/x86_64-linux-gnu/libX11.so

-- Found OpenGL: /usr/lib/libGL.so  

CMake Error at CMakeLists.txt:17 (message):

  glfw not found

But I already have GLFW installed >_<

Deleted User Accounts

Fri, 07 Sep 2012 20:55:08 +0000

We recently deleted most users with zero post count, if you happened to be included in that, we apologize. Kindly register again.

Bug: Spiky polygon syndrome :o

Thu, 06 Sep 2012 01:23:46 +0000

Here are pics of Wind Waker on my machine. Now that the shaders is somewhat fixed, the colors seem to be accurate. However... well take a look:

Now Shiz, even with the stripped down shader I get these SPS issues

Building an emu rig

Mon, 03 Sep 2012 19:31:58 +0000

So I finally got around to finalizing my build See below:

PCPartPicker part list / Price breakdown by merchant / Benchmarks

CPU: Intel Core i5-3570K 3.4GHz Quad-Core Processor ($209.99 @ NCIX US)
CPU Cooler: Thermaltake CLP0564 101.6 CFM CPU Cooler ($49.99 @ SuperBiiz)
Motherboard: ASRock Z77 Extreme4 ATX LGA1155 Motherboard ($114.99 @ Newegg)
Memory: G.Skill Ares Series 8GB (2 x 4GB) DDR3-1600 Memory ($54.99 @ Newegg)
Storage: Western Digital Caviar Black 2TB 3.5" 7200RPM Internal Hard Drive ($165.49 @ SuperBiiz)
Storage: Western Digital Caviar Black 2TB 3.5" 7200RPM Internal Hard Drive ($165.49 @ SuperBiiz)
Storage: Western Digital Caviar Black 2TB 3.5" 7200RPM Internal Hard Drive ($165.49 @ SuperBiiz)
Storage: Western Digital Caviar Black 2TB 3.5" 7200RPM Internal Hard Drive ($165.49 @ SuperBiiz)
Storage: Kingston HyperX 3K 120GB 2.5" Solid State Disk ($109.99 @ Newegg)
Video Card: VisionTek Radeon HD 7970 3GB Video Card ($439.99 @ Amazon)
Case: Antec Nine Hundred ATX Mid Tower Case ($96.39 @ Amazon)
Power Supply: Corsair 650W ATX12V / EPS12V Power Supply ($100.98 @ Newegg)
Optical Drive: Lite-On iHAS124-04 DVD/CD Writer ($14.98 @ Outlet PC)
Total: $1854.25
(Prices include shipping and discounts when available.)
(Generated by PCPartPicker 2012-09-03 15:24 EDT-0400)

I actually added 4 Western Digital Caviar Black 2TB's (that I previously owned), but didn't add it to the PCPartPicker list because I didn't want to show a bloated price. Configured as a RAID5.
I flashed the Radeon HD 7970 with the "GHz Edition" BIOS - that gave a nice improvement for cheap cheap!
When building this PC, I couldn't decide between the VisionTek HD 7970 and the EVGA GTX 670, as both TigerDirect and Newegg were offering coupons for $369.99 each (respectively), which is an absolute steal. So I bought both, with plans to return whichever seems worse. Feedback is welcome on this decision, especially with regards to overclocking. I'll give my feedback after I've done more testing, although I haven't even installed the GTX 670 yet.
3DMark11 Results for those interested ("Performance" mode).
I'm running the Windows 8 RTM via MSDN.
I've overclocked the 3570K to 4.4GHz

New member

Wed, 22 Aug 2012 13:44:32 +0000

Hello everyone, my nick is Diavolo i am from Rio de Janeiro, Brazil , I am willing to help with the project, although I do not understand anything programming, unfortunately. Sorry my english, Google Translate help me.

Zelda: Twilight Princess | New video core

Wed, 08 Aug 2012 22:59:33 +0000

Voila! Fixed some bugs that made this sucker go in game. Needs EFB copies to look right w/o wire mode.

Unofficial Gekko builds

Wed, 08 Aug 2012 03:21:10 +0000

Here is the latest Gekko Git CLI (and QT) build. CLI builds have no GUI and so you need to manually add the game path to your userconf.xml. In the shot below, you will see where you need to add the path to your game. If your path is correct, clicking "gekkorelease.exe" will load your game (if the game works with Gekko). Alternatively, you can use the "gekko_qtRelease.exe" which makes things easier with a GUI.

Here is where your game path needs to be specified when using CLI builds: userconf.xml: Path location

Windows - Gekko CLI 8-7-12 Build: Download

Windows - Gekko CLI and QT 11-1-12 Build: Download

Windows - Gekko CLI and QT 12-11-12 Build: Download

Windows - Gekko CLI and QT 4-5-13 Build: Latest Download

New builds will be posted here when necessary.

If you wish to post game shots, post them in the screen shot section, not in this thread.

Mario Kart: Double Dash | New Video Core

Thu, 26 Jul 2012 04:10:12 +0000

This one requires some hax to boot (which I haven't committed yet, but probably will soon).... I think it's very close to being right, but there is some crap in front of the screen so only wireframe is helpful

Seems to run fairly stable in game. Speed varies depending on the level (some of the levels are ~30fps in game with interpreter).

Ikaruga | New Video Core

Wed, 25 Jul 2012 15:37:40 +0000

Super Smash Bros. Melee | New Video Core

Tue, 24 Jul 2012 03:03:07 +0000

This one still looks sorta F**k'd up

Super Mario Sunshine | New Video Core

Tue, 24 Jul 2012 00:50:02 +0000

Blah blah blah new features

Good coding articles

Fri, 20 Jul 2012 16:08:16 +0000

**Sticky**
List of good programming articles/tutorials/etc that I've found and regularly reference, and are particularly helpful when coding with Gekko. I'll keep updating this post as I find more good stuff. Please add any good ones you know of!

A Successful Git Branching Model
Google C++ Style Guide

captnrhum tests | video core

Fri, 20 Jul 2012 14:39:05 +0000

Hello

This is a few tests on gekko 1.0

Viewtiful Joe:Red Hot Rumble

And then the game crash.

I must edit the gekko.ini configuration file if i'm not telling mistakes.

Zelda:The wind waker

Wireframe mod

Project64 v1.6 source released (unofficial)

Thu, 19 Jul 2012 23:03:39 +0000

In an effort to give the Nintendo 64 emulation scene a "push", one of the Project64 testers has released the source code to v1.6 to the public (unofficially, of course). You can access that here. It's been several years since the PJ64 has seen any activity and perhaps might be dead at this point. PJ64, coded by Zilmar and Jabo, is one of best Nintendo64 emulators. Hopefully this source will help to improve the currently active N64 projects (e.g. Mupen64+ and its various ports)! No word of approval/disapproval from the developers yet. PJ64 is technically at v1.7, however v1.6 includes the biggest improvements from the previous sourcecode release.

Read the full article on the blog.