Posted: 3/7/2015 7:22 PM
Post subject: Change the sprite position directly in VRAM?
Quote
CrazyTerabyte
He/Him
Joined: 5/7/2005
Posts: 74
I was playing Disney's Aladdin for Genesis and I thought about moving the HUD around. After reading about Genesis VDP, I discovered there is a Sprite Table located in VRAM. For this game, the table is located at 0xF400. Watching it on Hex Editor, during the title screen, we can clearly see the addresses 0xF406 and 0xF40E (16-bit integers) changing, corresponding to the X position of the "sword" in the main menu. Similarly, 0xF400 and 0xF408 correspond to the Y position. Then I tried poking that value, and freezing that value, but no luck. The sprite was still drawn the way the game intended. I also tried using Lua scripting to write a fixed value to VRAM, and again no luck. So, is there any way to poke/write/freeze values in VRAM? Any way to edit the data used by VDP before the frame gets drawn?
Posted: 3/7/2015 7:24 PM
Quote
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3599)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
TASer of 2010 NES TASer of 2010 DS TASer of 2010 Arcade TAS of 2010 NES TASer of 2008 NES TAS of 2008 Funny TAS of 2008 TASer of 2007 NES TASer of 2007 Funny TAS of 2007
You should try in 1.9.2, that sounds like something that was fixed in the past few months.
It's hard to look this good. My TAS projects
Posted: 3/7/2015 7:39 PM
Quote
CrazyTerabyte
He/Him
Joined: 5/7/2005
Posts: 74
Yep! I hadn't realized version 1.9.2 was released a couple of days ago. Which makes me wonder... Maybe a "auto-check for updates" feature might be useful in BizHawk. Just check for updates, but don't download them (just point the user to the URL). Of course, only if it is easy to implement.
Posted: 3/7/2015 7:39 PM
Quote
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3599)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
TASer of 2010 NES TASer of 2010 DS TASer of 2010 Arcade TAS of 2010 NES TASer of 2008 NES TAS of 2008 Funny TAS of 2008 TASer of 2007 NES TASer of 2007 Funny TAS of 2007
That was added to 1.9.2 as well, it is off by default though
It's hard to look this good. My TAS projects
Posted: 3/7/2015 7:46 PM
Quote
CrazyTerabyte
He/Him
Joined: 5/7/2005
Posts: 74
Damn, I spoke too soon. It seems that the X position can be changed, as well as which pattern and which palette is used to draw the sprite, but the Y position is fixed. Even changing the VRAM does not change the rendered sprite position. I don't know if I'm missing something technical here, or if this is actually a bug.
Posted: 3/7/2015 8:12 PM
Quote
feos
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11274
Location: RU
NES TAS of 2011
Can very well be read directly from ROM.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Posted: 3/8/2015 12:51 PM
Quote
marzojr
He/Him
Experienced player (749)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Sega TASer of 2014 Sega TAS of 2014 Sega TASer of 2010 Sega TAS of 2010
feos wrote:
Can very well be read directly from ROM.
It isn't; the sprite attribute table that resides in VRAM is self-sufficient, and contains all information needed to render sprites (except tile data, that resides elsewhere in VRAM). As a matter of fact, in the real VDP, the sprite attribute table in VRAM is not even used to render sprites — instead, it is copied to a cache RAM inside the VDP and this copy is used for rendering. All of this is done for speed; having to take the bus to read a word every now and then from RAM or ROM would be too slow, and copying it to this additional cache frees up VRAM bus for reading tiles.
Marzo Junior
Posted: 3/9/2015 1:07 AM
Quote
zeromus
Editor, Emulator Coder
Joined: 8/7/2008
Posts: 1156
Freezes suck and dont always work in this emulator due to being 'pulse-based cheats'. Moreover, it's possible that our implementation of pulsed cheats does not work correctly in GPGX in some video modes due to the architecture of that emulator caching a lot of stuff. I don't know what "mode 5" is but it's possible the sprite table is not poked correctly in that mode. We might need to use vdp_bus_w(). But I have no firm explanation for why the X coord works when the Y doesnt, except to say that Y coordinates and X coordinates are very different when it comes to sprite renderers and may be handled completely differently by such an overly clever emulator core.
Posted: 3/9/2015 5:39 PM
Quote
Xavos
Joined: 1/3/2015
Posts: 8
Unsure how much this will help, but freezing addresses doesn't seem to work well in the stable releases. When I attempt to freeze an address I'm watching it says it's frozen but the effects of the address continue as if it wasn't frozen at all. I've gone back to the Bizhawk r8948 dev release as freezing seems to work as intended there. Maybe try an earlier build and see if the sprite does what you want it too then?
Posted: 3/9/2015 5:40 PM
Quote
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3599)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
TASer of 2010 NES TASer of 2010 DS TASer of 2010 Arcade TAS of 2010 NES TASer of 2008 NES TAS of 2008 Funny TAS of 2008 TASer of 2007 NES TASer of 2007 Funny TAS of 2007
Are you saying freezing doesn't work in 1.9.2?
It's hard to look this good. My TAS projects
Posted: 3/9/2015 5:44 PM
Quote
zeromus
Editor, Emulator Coder
Joined: 8/7/2008
Posts: 1156
it sounds like he's saying freezing doesnt work (well) without telling us what platforms, games, addresses, or sizes arent freezing
Posted: 3/9/2015 6:03 PM
Quote
Xavos
Joined: 1/3/2015
Posts: 8
Well, I'm playing Romancing Saga on the SNES core. I watched and froze the addresses 000244, 0002C4, 016444 and 016544 at 2 byte size as they're counting the amount of times battle has been initiated (amount of times battle initiated influences what enemies you encounter and what side quests are available). However, after about 200 battles, early game sidequests locked out and enemy encounter sets in a single area had changed to a stronger set of enemies. Also, when unfreezing the value, it jumped up to a much higher number. Repeating the same thing in dev build r8948 seems to work as freezing the addresses, finishing one battle and then unfreezing the value doesn't result in the value changing to a higher value like in 1.9.2. Sorry if I'm wording things badly. I hope this helps though.
Posted: 3/9/2015 9:37 PM
Quote
Scepheo
Player (144)
Joined: 7/16/2009
Posts: 686
I have tested freezing and poking for both SNES cores, on both 1.9.2 and r8948 and everything works. It's not always perfect - this is probably due freezes actually being repeated pokes, which means values can change during a frame, but it definitely works. Which means you're probably using the wrong addresses or misunderstanding how the game uses them.
Posted: 3/9/2015 11:45 PM
Quote
Xavos
Joined: 1/3/2015
Posts: 8
That may be the case but I do believe I have the correct addresses as they are the only ones that are consistently counted after every battle, this would fit in with what limited prior documentation on Romancing Saga suggests too. I still need to do more testing in r8948 to make sure that it works (going to play through an entire prologue fighting every available battle) and see if the same things happen that occurred in 1.9.2 or if it does what I'm hoping for or something else entirely. If after the prologue I find myself locked out of early game quests and encounter significant increased enemy strength I'll assume there's more than just the battle counter that influences these things. The current documentation for Romancing Saga isn't worded well and isn't clear if the in game clock has any bearing on the issue. If results are the same in both 1.9.2 and r8948 I'll find out the addresses for the game clock and test those too along with the battle counter addresses. I'm hoping things work out the way I want as a full fan translation of Romancing Saga is due for release soon. I'd like to try and document the game algorithms and make a guide on how certain side quests effect one another. This would be much easier if I find a way to freeze what decides to lock certain quests as the sheer amount of enemies and difficulty of avoiding them ensures you'll be locked out of quests through playing the game normally. If there is an issue with Bizhawk though I'd be happy to help with testing specific things in a variety of games. Bizhawk has the best UI, especially so for RAM searching and watching so I wouldn't like to have to go back to Snes9x to document games. EDIT: I suppose I should link the only site I know with any significant data on Romancing Saga so far as it might help explain my point a bit. Unfortunately it's all in Japanese but Google Translate should be good enough even though it fails to understand context. http://www8.plala.or.jp/alice4/ And this page of the site explains a bit on the battle counter. http://www8.plala.or.jp/alice4/74.htm#00 If the battle counter starts at 0 and counts up to 65535 as the site suggests then logically I should find the addresses that increase their values by 1 at the end of battle yes? The 4 addresses I've noted are the only addresses that do this so they should be the ones I must monitor and freeze. I will start conducting some more testing in r8948 once I get back home from work later today. EDIT2: I have completed testing a playthrough of Albert's prologue (this one requires the most fights) in Romancing Saga using Bizhawk dev build r8948 with the addresses I've frozen. Early game side quests are available and I never encountered a stronger enemy set despite doing even more fights than my playthrough using 1.9.2. I'm convinced that address freezing does not work in 1.9.2 but does work with r8948 after this. Hopefully this info can help resolve the issue but I can do further in game testing if that's necessary, may test other games too and see if it's an issue that only effects certain games.