All Posts (blitter)




#1
Re: Linux Support
Posted on: Today 4:55
Nintendoid!
Joined 2007/12/14
104 Posts
CoderLong Time User (6 Years) App Coder
I've built gccVB 4 under OS X, both PPC and Intel, and combined with Eclipse is how I do all my VB development. The FlashBoy software though is relegated to a PC with I believe a flaky motherboard, so I'll have to find a solution for that one of these days. As far as I know the FlashBoy software is Windows-only, so you'd either have to use WINE/CrossOver or write one yourself-- seems somebody has figured out the protocol... http://www.planetvb.com/modules/newbb ... ost_id=8666#forumpost8666 ...
Top

Topic | Forum


#2
Re: Oculus Rift +VB emulator
Posted on: 9/28 18:53
Nintendoid!
Joined 2007/12/14
104 Posts
CoderLong Time User (6 Years) App Coder
Quote:

HorvatM wrote:
I'm surprised there isn't the same amount of myths/criticism/superstition surrounding it as the VB, which, IMO, is for now simply a better product. Maybe because it's got John Carmack behind it? Gunpei Yokoi apparently wasn't a good enough celebrity.


For one thing, Oculus is making a big deal out of the fact that they are developer kits and there are warnings and guidelines everywhere about keeping latency down, using the proper projections, crafting the experience to minimize disorientation, etc. They have a whole team at Oculus dedicated to this kind of cognitive research, whereas with the VB Nintendo just put together documentation basically saying "This is how 3D works on the VB, good luck!"

The default IPD on the Rift is pretty reasonable-- 64mm, which according to statistical research is the military average-- and unlike the VB, the field of view is much *much* larger. That last bit alone is a big part of why the Rift is getting such widespread praise-- no other consumer-focused headset before it has been able to achieve such immersion. I love the VB too, but there's no denying that the Rift provides a much better VR experience. The VB by comparison is just a toy. There really shouldn't be a comparison.
Top

Topic | Forum


#3
Re: Oculus Rift +VB emulator
Posted on: 9/28 9:41
Nintendoid!
Joined 2007/12/14
104 Posts
CoderLong Time User (6 Years) App Coder
retronintendonerd are you a developer? Getting a DK2 now if you're not a developer would be a waste of money, as the new Crescent Bay makes it obsolete in every way. (I played with it at OC last weekend). Odds are, given what happened with the DK1->DK2 switch, another SDK refactoring is coming-- by that time, the DK2 won't be compatible with anything anymore. I'd hold off until CV1.
Top

Topic | Forum


#4
Re: Is the VB more like Game Boy or SNES to you?
Posted on: 9/25 1:01
Nintendoid!
Joined 2007/12/14
104 Posts
CoderLong Time User (6 Years) App Coder
I tell people unfamiliar with the system that it's the processing power of a SNES with a SuperFX chip combined with the color depth and sound hardware of the Game Boy. Not quite 100% accurate, but close enough and mostly gets the point across. :)
Top

Topic | Forum


#5
Re: Project VBoot
Posted on: 9/24 4:05
Nintendoid!
Joined 2007/12/14
104 Posts
CoderLong Time User (6 Years) App Coder
My only request is the ability to fill the VB's entire ROM address space. I don't care what it looks like; I want a flash cart that I can use to build larger games. :)
Top

Topic | Forum


#6
Re: RFC: Standardized interrupt vectors
Posted on: 9/12 9:36
Nintendoid!
Joined 2007/12/14
104 Posts
CoderLong Time User (6 Years) App Coder
Out of curiosity, are you working on a project that uses some of the aforementioned unemulated features? If so I'm very curious what for. (And would love such projects to lead to Mednafen bug fixes)
Top

Topic | Forum


#7
Re: RFC: Standardized interrupt vectors
Posted on: 9/12 9:26
Nintendoid!
Joined 2007/12/14
104 Posts
CoderLong Time User (6 Years) App Coder
Unless your project relies on features that Mednafen currently struggles with, I still don't see why testing against hardware so often is necessary. Mednafen is more than good enough for constant iteration on most projects.

If you encounter a bug in Mednafen that needs fixing, do what I've done and write a patch for Ryphecha. That's the beauty of open source. ;)
Top

Topic | Forum


#8
Re: G&P Monthly
Posted on: 9/1 16:51
Nintendoid!
Joined 2007/12/14
104 Posts
CoderLong Time User (6 Years) App Coder
One feature request: importing of MIDI files. There are already a lot of excellent MIDI sequencers out there (some commercial-grade), and I for one don't relish the thought of learning a new composing tool. ;)
Top

Topic | Forum


#9
WRAM access optimizations
Posted on: 8/29 6:27
Nintendoid!
Joined 2007/12/14
104 Posts
CoderLong Time User (6 Years) App Coder
My PCM mixer runs fine on its own but slows execution down to a crawl when paired with music and rendering, so I'm looking to optimize it wherever I can, including dropping down and rewriting parts of it in assembly where practical. When examining the output of building with both -Os and -O3 in gccVB 4, though, I noticed the following peculiar pattern when accessing variables kept in WRAM:


movhi hi
(_masterMusVolume),r0,r10
    ld
.b lo(_masterMusVolume)[r10],r14
    movhi hi
(_noiseVolume),r0,r27
    movhi hi
(_musDataStart),r0,r10
    movhi hi
(_freeVSUChannelCur),r0,r25
    movhi hi
(_noiseVelocity),r0,r26
    movhi hi
(_noiseLeft),r0,r29
    movhi hi
(_noiseRight),r0,r31
    ld
.b lo(_noiseVolume)[r27],r11
    ld
.w lo(_musDataStart)[r10],r18
    movhi hi
(_vbTranspose),r0,r10
    ld
.w lo(_vbTranspose)[r10],r10
    ld
.b lo(_freeVSUChannelCur)[r25],r17
    ld
.b lo(_noiseVelocity)[r26],r23
    ld
.b lo(_noiseLeft)[r29],r22
    ld
.b lo(_noiseRight)[r31],r12


Since WRAM on the VB is located at 0x05000000 and therefore aligned on a 64KB boundary, wouldn't it be more economical to, say, movhi hi(_WRAMStart),r0,r10 just once and then ld lo(_variable)[r10] subsequently for each WRAM access? Why doesn't the code do this or something similar?

I could rewrite this particular routine in assembly (it runs over 8000 times a second via the timer interrupt, so it needs to be as fast as possible) but this kind of code is generated all over the place whenever WRAM is read or written, so that to me just seems like putting a band-aid over a larger problem. Is this a bug in gccVB or is there a way to coax the compiler into generating more efficient code here?
Top

Topic | Forum


#10
Re: PCM and speaker pops
Posted on: 8/27 5:40
Nintendoid!
Joined 2007/12/14
104 Posts
CoderLong Time User (6 Years) App Coder
Thanks Guy Perfect!

In my first post I tried adding a fade in/out to my sound files as you suggested but that had no effect on the popping. However, what you said got me to take a closer look at the raw sound data, and that got me thinking (always a scary thing). My mixer was resetting LRV to 0 when there were no samples to play, and my sound data is converted from unsigned 8-bit PCM to unsigned 4-bit. *But,* unsigned PCM is more like "offset PCM," centered around 0x80, not 0 as I had incorrectly assumed. So... I added a tiny bit of code that resets LRV to 0x88 when no samples are present, and now the pops are gone, both on hardware and in Mednafen. :)

Attach file:



png  Screen shot 2014-08-26 at 8.32.50 PM.png (93.37 KB)
676_53fd530c4381b.png 1920X599 px
Top

Topic | Forum




You are not logged in.
Lost Password?
Register Resend Activation