Search found 57 matches

by ARM9
Sat Mar 18, 2017 8:24 am
Forum: SNESdev
Topic: Fast 3D blitting on Super FX
Replies: 17
Views: 10972

Re: Fast 3D blitting on Super FX

Wait, really? I would have thought it would be the size. I understand that even the "relatively fast" stuff still has the potential to be enough to put it over the edge, but you also said the framerate drops when the objects are closer to the camera. It'd be more efficient to render one l...
by ARM9
Fri Mar 17, 2017 4:00 pm
Forum: SNESdev
Topic: Fast 3D blitting on Super FX
Replies: 17
Views: 10972

Re: Fast 3D blitting on Super FX

The frame rate depends heavily on the amount of polygons that actually get drawn, the rest is relatively fast. I switched to 2bpp and it's just about breaking 60fps if the objects don't get too large, you can see it dip down to 30 as they get closer to the camera. https://www.dropbox.com/s/448s5i5wi...
by ARM9
Wed Mar 15, 2017 1:18 pm
Forum: SNESdev
Topic: Fast 2D blitting on Super FX
Replies: 23
Views: 20186

Re: Fast 2D blitting on Super FX

Very cool tech demo, great to see more people programming the superfx! If you were to target PAL you could do 4bpp at 50fps. One problem with double buffering is that no cart has more than 64K ram, so if someone were to do double buffering at 8bpp they'd either have to gut the resolution or put 128K...
by ARM9
Sun Jan 15, 2017 2:52 pm
Forum: SNESdev
Topic: Fast 2D blitting on Super FX
Replies: 23
Views: 20186

Re: Fast 2D blitting on Super FX

Yeah, but according to the manual, dither doesn't handle transparent pixels properly, because it determines which nibble to use in parallel with checking whether the bottom nibble is zero. That's right, reminds me of a test rom that seems to indicate emulators get this wrong, which is understandabl...
by ARM9
Wed Jan 11, 2017 8:52 am
Forum: SNESdev
Topic: Fast 2D blitting on Super FX
Replies: 23
Views: 20186

Re: Fast 2D blitting on Super FX

EDIT: Just had an idea: getb inc R14 color plot mult R3 ; where R3 contains 0010h swap color loop plot Okay, never mind; that's a bit slow. It handles gaps fine, but it can just barely keep up with 4bpp blitting, which means that with metadata handling between lines, this method is probably bottlen...
by ARM9
Sun Jun 28, 2015 5:20 am
Forum: SNESdev
Topic: GSU revision comparison test
Replies: 32
Views: 10167

Re: GSU revision comparison test

Wow that is really close, nice one. and have to resort to desoldering the ROM, cleaning the rosin flux off the pins, reprogramming the chip in a socket, then resoldering it... I wish it was as easy as the Cx4 :( Ouch, that's quite an arduous process. I'm making a test suite so you don't have to repr...
by ARM9
Fri Jun 26, 2015 10:40 am
Forum: SNESdev
Topic: GSU revision comparison test
Replies: 32
Views: 10167

Re: GSU revision comparison test

I was planning to make a more thorough cache test to check any edge cases there such as how cache lines are loaded, fetching stalls, various invalidation methods (what happens if you write to < xxxfh in a cache line from scpu f.ex) and such.
by ARM9
Fri Jun 26, 2015 10:21 am
Forum: SNESdev
Topic: GSU revision comparison test
Replies: 32
Views: 10167

Re: GSU revision comparison test

AWJ wrote:Why does this ROM depend on cache behaviour when the previous one didn't?
I think it's just the granularity of the counter that's too coarse on the previous one, I could make the scpu loop shorter (at the cost of more complexity).
by ARM9
Fri Jun 26, 2015 9:36 am
Forum: SNESdev
Topic: GSU revision comparison test
Replies: 32
Views: 10167

Re: GSU revision comparison test

ARM9, can you write another program that tests these two instructions? Here you go: https://dl.dropboxusercontent.com/u/13494639/snes%20stuff/mult.sfc Source: https://github.com/ARM9/snesdev/tree/master/gsu/mult There might be some cache issues involved in this one, writing 0 to the Go flag in the ...
by ARM9
Thu Jun 25, 2015 5:45 am
Forum: SNESdev
Topic: GSU revision comparison test
Replies: 32
Views: 10167

Re: GSU revision comparison test

Ah yes, I recognize that screen, thanks for taking the time to run it on hardware, very much appreciated. I made that rom to test whether the fast multiplication setting worked in 21mhz mode. Book says no, so does bsnes, yet some superfx games I've looked at seem to use it at 21mhz so I wanted to se...
by ARM9
Sun Apr 26, 2015 3:32 am
Forum: SNESdev
Topic: bsnes-plus and xkas-plus (new debugger and assembler)
Replies: 210
Views: 206619

Re: bsnes-plus and xkas-plus (new debugger and assembler)

bsnes-plus (or bsnes+) is a fork of bsnes (based on bsnes-classic) intended to introduce some new features and improvements, mostly aimed at debugging. Very cool, thanks a lot for your effort, I can see myself using this one a lot. I wonder, does this debugger have any support for keybinds? I might...
by ARM9
Mon Apr 13, 2015 1:37 pm
Forum: SNESdev
Topic: DMA reset using DMA? [Apparently not...]
Replies: 8
Views: 3823

Re: DMA reset using DMA?

Are you writing vram during vblank? iirc both zsnes and no$sns allow writing to vram during scanning, which would not write vram on a real console. I would suggest removing zsnes from your tests as it's a broken mess that'll only waste your time. And don't trust no$sns too much, it's the most accura...
by ARM9
Fri Mar 06, 2015 11:33 am
Forum: SNESdev
Topic: Were any commercial SNES games written in C?
Replies: 37
Views: 18741

Re: Were any commercial SNES games written in C?

I'm really septic about the fact that Doom on SNES was coded in C, is there any C compiler for the SuperFX in first place ? I don't think so... There's no official argonaut or nintendo C compiler for the GSU, but iirc carmack has dabbled in compiler development so it's certainly a possibility. I mi...
by ARM9
Wed Feb 18, 2015 2:33 pm
Forum: SNESdev
Topic: Documentation on offset-per-tile
Replies: 18
Views: 8240

Re: Documentation on offset-per-tile

tepples wrote:Are those effects emulated properly in a debugging emulator like NO$SNS? If so, open them and see how they're arranging BG3.
Nope.png, but you can still watch the map in the vram viewer.