I still have a very odd bug that I've had from the beginning though; when compiling gens from scratch VS always fails to link pwm.asm. if I try building again (not rebuilding) it links fine and finishes building gens.
DDRKhat wrote:
they will run into a issue because of pwm.c if they simply rename it to pwm1.c in the studio, then it'll compile fine.
Tried the SonicMapHack, looking through the source I need ScrollLock enabled. However even if I do, it doesn't matter what I press, the screen will NOT move.
I still have a very odd bug that I've had from the beginning though; when compiling gens from scratch VS always fails to link pwm.asm. if I try building again (not rebuilding) it links fine and finishes building gens.
DDRKhat wrote:
they will run into a issue because of pwm.c if they simply rename it to pwm1.c in the studio, then it'll compile fine.
Tried the SonicMapHack, looking through the source I need ScrollLock enabled. However even if I do, it doesn't matter what I press, the screen will NOT move.
Disable numlock.
How fleeting are all human passions compared with the massive continuity of ducks.
I also seem to have some bizzare issue. I've compiled this fine however when I run the created Gens.exe , whenever it applies a rendering mode (even when it's first loading up) it for some bizzare reason takes the entire width of BOTH of my screens.
The project should be compiled with VS2005, not VS2008. (They both have free versions available.) However, I would be interested in seeing a screenshot of this problem at the moment since your description is somewhat vague. (are you in fullscreen mode? is it maximized? can you resize the window to make it better? is it drawing outside of the window? does it happen with all the different render modes? what exactly does "whenever it applies a rendering mode" mean, does that mean it only happens while a render mode message is onscreen?)
Already did. still not able to move the camera. it moves a little bit but I still seem to be in control of sonic.nitsuja wrote:
The project should be compiled with VS2005, not VS2008. (They both have free versions available.) However, I would be interested in seeing a screenshot of this problem at the moment since your description is somewhat vague. (are you in fullscreen mode? is it maximized? can you resize the window to make it better? is it drawing outside of the window? does it happen with all the different render modes? what exactly does "whenever it applies a rendering mode" mean, does that mean it only happens while a render mode message is onscreen?)
I only have 2008, also there should not be any compatibility issues between the two.
Freshly compiled Gens.exe, no hacks enabled. Initial load. Sonic 1 Jap rom. Img here
Same loading, Chosen a different rendering mode.
Img here
Yes the window is still resizable, but upon choosing a new render mode I have to resize it once again.
Already did. still not able to move the camera. it moves a little bit but I still seem to be in control of sonic.
The camera is not controlled with the joypad buttons... it uses IJKL.
(also . to refocus on sonic and , to teleport sonic to screen center)
You said it wouldn't move no matter what you pressed so I thought you had, like, tried pressing keys other than your pad assigned ones.
How fleeting are all human passions compared with the massive continuity of ducks.
Already did. still not able to move the camera. it moves a little bit but I still seem to be in control of sonic.
The camera is not controlled with the joypad buttons... it uses IJKL.
(also . to refocus on sonic and , to teleport sonic to screen center)
You said it wouldn't move no matter what you pressed so I thought you had, like, tried pressing keys other than your pad assigned ones.
Sorry for the mis-understanding. I was reading through it and only saw reference to keyup (something similar to it anyway) I had asked for how to control it earlier but it seems nobody wanted to answer me.
Also, it doesn't seems to be placing things wrong in some fashion, I guess this was a newly implemented hack which is still being worked on? the below screenshot was simply done by moving around.
Sonic games don't like forced leftward or upward camera movement. make a savestate at the left edge, and always scroll right/downward.
Though I actually have commited to the SVN a version that fixes that for Sonic 2 (but only Sonic 2).
How fleeting are all human passions compared with the massive continuity of ducks.
It (the "sonic maphack") is more of an old hack, I wouldn't call it newly-implemented... it's been updated occasionally but, yeah, you have to use it very carefully to get correct results and it's not part of the released Gens exe for a reason. It was really only for programmers that are willing to fully understand it.
Also, now that there's Lua support it's entirely possible to write a Lua script that loops through the level's screens and dumps out an image of it. Game-specific hacks in the C++ code are less necessary now. (Admittedly, heavy image processing is probably the worst example of what to move over to Lua, but it can be done and you'd have full control over what it's doing.) That goes for things like camhacks as well. If I were to make a new camhack for a Genesis game I'd certainly do it in a Lua script.
Also, now that there's Lua support it's entirely possible to write a Lua script that loops through the level's screens and dumps out an image of it.
But this would have the character actively moving at the period, would it not? So objects such as badniks (in this case) would not always be in the same location?
Also, now that there's Lua support it's entirely possible to write a Lua script that loops through the level's screens and dumps out an image of it.
But this would have the character actively moving at the period, would it not? So objects such as badniks (in this case) would not always be in the same location?
I don't think the C++ based maphack attempts to solve that problem either. It's not as much of a problem as it sounds because generally the game won't update things that are offscreen, so as long as you scroll through the level at a fixed speed then most objects will be positioned a consistently small distance from their starting positions.
But, I suppose the script could load a savestate before every screenshot to make sure that all the screenshots get taken at the same emulation time.
Also, depending on the game, there might be some way to pause the game without disabling camera movement. For some games that can be done simply by writing something to RAM, but even if that won't work, I believe you could tell the game to actually "skip over" the non-camera update code with something like this:
Also, now that there's Lua support it's entirely possible to write a Lua script that loops through the level's screens and dumps out an image of it.
But this would have the character actively moving at the period, would it not? So objects such as badniks (in this case) would not always be in the same location?
My approach to this problem was to hack the game and remove all the motion, rather than hacking the emulator to paralyze the game. Although Sonic CD would almost have to be an exception to that approach, since each time zone of each act of each round is a completely separate program.
How fleeting are all human passions compared with the massive continuity of ducks.
A few bug fixes, one somewhat major.
New in version 11a:
Loading roms and such from command line no longer requires use of the -rom [or relevant] command line switches (nitsuja)
More emulation variables properly initialized on ROM load (nitsuja)
FrameCounter positioning now adjust so that it will not run past the right edge of the screen. (upthorn)
Fixed automatic gmv backup bug where [movie_name].bak.gmv would become the current version and [movie_name].gmv the unmodified backup. (upthorn)
Added desync warning when playing a movie from a savestate that has no input data saved in it whatsoever. (upthorn)
Fixed bulletproof rerecording and desync detection compatibility with savestates from recently obsoleted gens versions. (upthorn)
Get it here:
Executable, with source package update patch included.
Still looking for a linux coder. Send me a forum PM, or email me at upthorn@gmail.com if you can program for Linux and are interested in joining the gens rerecording project.
How fleeting are all human passions compared with the massive continuity of ducks.
Many many thanks to Upthorn, nitsuja and adelikat for this! All the problems I reported with release 10 (background input, no difference between right/left shift) are solved, and a very fast fix with 11a.
Another problem I had is also solved, but I don't see a change note for it. Is was that the Gens screen would be blacked out after the computer had been in sleep mode, which demanded restart, change of render mode or similar.
Another problem I had is also solved, but I don't see a change note for it. Is was that the Gens screen would be blacked out after the computer had been in sleep mode, which demanded restart, change of render mode or similar.
Oh yeah, almost forgot I fixed that. It also used to happen if you change between 16 and 32 bit color while Gens is open. In that case it still goes black for 1 frame, which you'll notice if Gens is paused, but simply unpausing fixes it (no need to change render modes). Also fixed is that, if for whatever reason you have hardware video acceleration completely disabled, Gens should still work (albeit with restricted available render modes).
One other thing I didn't see mentioned specifically in the changes: RAM search and RAM watch are must faster now (than in Gens10) so you can leave them open without the emulation slowing down much if at all. And the controls for what happens when left+right/up+down are disabled have been improved (holding left and right will go right, or holding right and left will go left).
Question. I know Gens has blargg's NTSC video filter built in, is it possible to make the avi dump happen after the video filter is applied instead of the raw 320x240 (approximate) Gens output?
I don't believe that's possible in any gens rerecording version that's been released so far, because it isn't in line with the site's goal of unmodified output.
I could look into implementing it as an option, but it's not exactly the top of the priority list.
How fleeting are all human passions compared with the massive continuity of ducks.
The option would be super freaking sweet to have.
I like making tas dvds to watch while out on the road and it makes those infinitely easier to make while also keeping things looking like I remember (crappy tv) growing up.
I wish I had some programming skills I could use to contribute with. The only thing I guess I can do is finally finish my perfect score run of Double Switch for SegaCD, ha.
I hope it doesn't bug you guys when I chirp in once a year with stupid requests. I've been following everything you guys do pretty damn regularly for sev years now. See reg date. I just don't post unless I think I have something legitimate to add.
I do however have a 100% complete US SegaCD collection (not pirated, real games in big blue cases), if anyone needs to borrow a quality copy of a game they want to run.
Perhaps I'm thinking of the new Kega build that just came out a few months back.
Let me revise my earlier post...
Suggestion! (low on the priority list, ha)
Implement blargg's NTSC filter and give option to allow avi dump after filter.
...pretty please?
because it isn't in line with the site's goal of unmodified output.
Bisqwit has said many times that he would prefer to have AVI videos with the NTSC filter on them; but we still don't have any emulator capable of doing that, I believe.
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
because it isn't in line with the site's goal of unmodified output.
Bisqwit has said many times that he would prefer to have AVI videos with the NTSC filter on them; but we still don't have any emulator capable of doing that, I believe.
Err, I meant that dumping AVIs after they've been NTSC filter would require moving the AVI dumping call to _after_ the filter is applied, thus allowing AVIs to be dumped in 2xsai, hq2x, etc. I was not referring to the NTSC filter specifically.
How fleeting are all human passions compared with the massive continuity of ducks.
Well, allowing != forcing
Even if you move the AVI dumping routine there, the cool people will always get 1x AVI files. To be completely honest I never understood what passes through someone's mind when he decides to enable any kind of filter, if it was for me I would force any emulator to always output unfiltered stuff, but that's just me. Since people like eye candy, give them eye candy.
because it isn't in line with the site's goal of unmodified output.
Bisqwit has said many times that he would prefer to have AVI videos with the NTSC filter on them; but we still don't have any emulator capable of doing that, I believe.
Err, I meant that dumping AVIs after they've been NTSC filter would require moving the AVI dumping call to _after_ the filter is applied, thus allowing AVIs to be dumped in 2xsai, hq2x, etc. I was not referring to the NTSC filter specifically.
I never said you didn't mean that. :P I just said the site's goal is not "unmodified output", but "output as close as the real thing as possible".
nineko wrote:
Well, allowing != forcing
Even if you move the AVI dumping routine there, the cool people will always get 1x AVI files. To be completely honest I never understood what passes through someone's mind when he decides to enable any kind of filter, if it was for me I would force any emulator to always output unfiltered stuff, but that's just me. Since people like eye candy, give them eye candy.
The NTSC filter is hardly "eye candy", it makes all look really shitty, but that's how it looked on real NTSC TVs...
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
Well, allowing != forcing
Even if you move the AVI dumping routine there, the cool people will always get 1x AVI files. To be completely honest I never understood what passes through someone's mind when he decides to enable any kind of filter, if it was for me I would force any emulator to always output unfiltered stuff, but that's just me. Since people like eye candy, give them eye candy.
I def agree with you that most filters that get built into emulators by default definitely take away from the overall presentation. The NTSC filters that blargg made work very differently than any other filter I've seen.
Here is a great example
http://blargg.fileave.com/ntsc-vs-palette/
A lot of artists/programers actually counted on this kind of blending when they made the art for certain titles to give the effect of more colors. Eternal Champions for SegaCD immediately comes to mind. The dithering on almost all SegaCD full motion video counted on this as well.
The blargg filter is also the only one I'm aware of in the emulation community that does the proper interlacing of a 240p signal down to 30 progressive frames per second. See: http://en.wikipedia.org/wiki/240p
It's something that the younger people who grew up playing these games through emulation and not on a real console won't get because they are so used to seeing perfectly square pixels.
