 |
|
 |
|
Views: 305,957,572
Time: 2014-07-31 02:23:05 AM | 16 users online: Daizo Dee Von, Extroble, Gible_v, GutterGhoul, JackTheSpades,  mariocool1999, mockingod, MrDeePay, NGB, pakkie, RealMarioGamer, Retrodeath, Rovio Fan, Subrosian, Wiimeiser, Wuthering - Guests: 28 - Bots: 84 | Users: 25,341 (1,247 active)
Latest: GutterGhoul |
|
|
 |
|
|
|
| Tip: Check this thread to find extremely useful diagrams and data. |
|
|
|
|
|
|
|
 |
|
 |
|
| Posts by smkdan |
|
|
|
|
|
|
|
|
Originally posted by InitialBNI know that this is sort of an old post, but WHY exactly is this impossible?
The SNES can't rotate tiles like that. Only X and Y flipping is possible. The best you would get is a feature that rotates a map16 tile and generates four new 8x8 tiles that are pre-rotated but that needs extra GFX space unlike X/Y flips. It wouldn't be any different than if you just manually roated the tiles yourself.
|
|
| (restricted) | | (restricted) |
|
|
I had a look at look at emulator source and some cart docs a while back and it looks like 708000/F08000 etc. are safe to use for ROM in any modern emulator.
bsnes from a while ago:
Code //research shows only games with very large ROM/RAM sizes require MAD-1 memory mapping of RAM
//otherwise, default to safer, larger RAM address window
uint16 addr_hi = (memory::cartrom.size() > 0x200000 || memory::cartram.size() > 32 * 1024) ? 0x7fff : 0xffff;
map(MapLinear, 0x70, 0x7f, 0x0000, addr_hi, memory::cartram);
if(cartridge.mapper() != Cartridge::LoROM) return;
map(MapLinear, 0xf0, 0xff, 0x0000, addr_hi, memory::cartram);
snes9x 1.53:
Codevoid CMemory::map_LoROMSRAM (void)
{
map_index(0x70, 0x7f, 0x0000, 0x7fff, MAP_LOROM_SRAM, MAP_TYPE_RAM);
map_index(0xf0, 0xff, 0x0000, 0x7fff, MAP_LOROM_SRAM, MAP_TYPE_RAM);
}
Older/smaller games without MAD-1 on the cart put SRAM at 708000+ but MAD-1 games don't. The newer/bigger games work fine when reading ROM from those areas. A ROM that is big enough to require the 708000+/F08000+ area should have no problem using it. I tried a SMWCP2 ROM which is 4MB lorom and ROM shows up at 708000/F08000 like it should in bsnes 080 memory viewer.
|
| Last edited on 2012-01-17 08:30:56 PM by smkdan. |
|
|
|
If you are new to programming, I'd go with the least painful way of getting familiar with the concepts before worrying about efficiency. Python is a great first language with far less potential stumbling blocks compared to most others, especially C++. You're going to make a ton of mistakes early on so it's better to start with a language that minimises the amount of cryptic bullshit you have to deal with. Python is great for that. It's a bad idea to worry about 2) this early on. It's not the most efficient but once you get the concepts down, jumping to another language isn't so hard if you find it's too slow for your needs.
I use C++(11) and C# mostly depending on the app requirements and I usually go with the latter. I wouldn't recommend either as a first language though. If you do have interest in Java, I suggest you atleast have a look at C# first unless you know well in advance that it won't work on the platforms you'd want to use. That's C#'s big weakness but Java as a programming language is awful by comparison, even with fundamental stuff. There's so many things it's either lacking in or has awful implementations of. You won't have that much trouble learning one after you've learned the other though.
edit: just realised this should be in programming instead. I'll move it over.
|
| Last edited on 2012-01-20 11:41:25 PM by smkdan. |
|
| (restricted) | | (restricted) | | (restricted) |
|
|
|
There's a bug that I caught a while ago that can cause a crash if rare requirements are met. It's fixed and ready for the next BT but I might either patch it if ends up taking a while. PM me the ROM with your steps followed that causes this crash and I'll confirm the issue.
|
|
| (restricted) | | (restricted) |
|
|
The asl $4216 is enough of a delay but that's a dangerous way to do it. What are the next few lines of code? You could probably remove any delay stalling by reorganising it.
Originally posted by Kipernal
Code94f64c lda $03 [000003] A:0000 X:00a8 Y:003c S:01e6 D:0000 DB:7e nVMXdiZc V:116 H: 460
94f64e sta $4202 [7e4202] A:00db X:00a8 Y:003c S:01e6 D:0000 DB:7e NVMXdizc V:116 H: 484
94f651 lda $00 [000000] A:00db X:00a8 Y:003c S:01e6 D:0000 DB:7e NVMXdizc V:116 H: 516
You have the DB set to 7E here which means you're reading/writing RAM instead of the hardware. It's easy to get caught by that when using 16bit addressing if you forget what the DB currently is.
|
| Last edited on 2012-03-03 11:00:59 AM by smkdan. |
|
| (restricted) |
|
|
I forgot all about adding coprocessors to SMW. We had SMW+superfx/sa-1 demos a long time ago but they never caught on for various reasons that aren't really issues anymore. If it does catch on this time, SA-1 is definitely the way to go. There's plenty of documentation, it's easy to use and it's the most flexible.
Some other nice-to-have things might be fast decompression/level building to cut load times. There's also the idea of vblank speedups by getting the sa-1 to generate the fastest possible code each frame by sharing any needed data with it, then just having the SNES jump to the code in RAM within NMI. It would mostly consist of a long stream of immediate loads and stores to DMA registers with direct page used for space/speed benefit. That can help raise the exanimation ceiling a fair bit.
|
| Last edited on 2012-03-11 08:12:41 AM by smkdan. |
|
|
|
Originally posted by Vitor VilelaAbout rotation, this transformation is done for each pixel:
x' = (x * cos(r)) - (y * sin(r))
y' = (x * sin(r)) + (y * cos(r))
SA-1 was doing well on this formula, as you can see in my videos that was good. But the problem would be to actually optimize as they would have to loop through width * height of bitmap.
Are you doing all that math for every pixel or has it been optimised arleady? It should be very fast at 10MHz with code that calculates start position once and then just adds deltax/deltay to the source pixel position.
Originally posted by imameliawhat about your VRAM hacks? Couldn't then be SA-1-ified as well?
It would work a lot better if the level data was on cart RAM but there's still plenty of potential speedup. There's a few ideas I have to make it run better if SA-1 ever gets popular. There's also another idea that can be done with just the SNES (but SA-1 assistance would also help) that might appear in later versions if Fusoya agrees to updating it.
|
|
| (restricted) | | (restricted) | | (restricted) | | (restricted) | | (restricted) |
|
|
|
|
|
|
|
|
 |
|
 |
The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.
Copyright © 2005 - 2014 - SMW Central
Legal Information - Privacy Policy - Link To UsTotal queries: 27
|
|
|
|
