Print

[XPort]

Possibly has something to do with the initialization (or reinitialization) of g_pBlitBuf (if this is one of the titles in which it is used).  Check to see if the same thing happens when using software video filters (2xsai etc) vs. no-filters.  It could also be related to the g_pDeltaBuf (I think that's what it's called) if it only happens in software video filters.

[madmab]

Wow.... just a quick glance at Vice64, Z26, and Winuaex the render_to_texture is quite different for each.  Although Winuaex seems to be the closest.  

Are they different for a reason?  Or are they just various "evolutions" of that code?  Should I look at one of the other emu sources for a transplant?  Or is the fix simpler than that?

Thanks...

[madmab]

I've been kinda slacking on listing changes I've been doing, so here goes..

Cleaned up some of the menu structures so they work like they are "supposed" to.  It's funny how easy it is to  overlook small stuff like that when your excited about a feature added.  

Fixed a few interface "quirks" regarding game sounds playing while emu is paused.

Added in the ability to turn on/off player/missile/playfield collisions (for cheating).  Try it on games like Pacman or Jumpman.  The collision setting is not saved on exit, but the sprite collision detection settings are saved on exit.  So all it takes is a simple hop into the options menu to re-activate it.

Went ahead and threw in Dual Analog support!  Yeah Dual Robotron and Space Dungeon baby!! Just check out the configuration screen, enable dual analog, and you should be set.

Autoselect media automatically brings up the cartridge select screen if the media type is a cartridge.

Added in 3 extra cart types (Atari Max and Spartados X 128)

Changed Two Chip 16 KB 5200 cartridge to be more descriptive (Atari Proto's use this).

Mapped the 5200 reset button for games that use it (Countermeasure).  Currently mapped to black+white
combo.

Modified swap joystick ports 1 & 2 so it works in 5200 mode (for the ONE game that supports it)

Player missile collisions work properly in fast forward mode.

Some menu changes. Specifically.. (still fine tuning this)

Split the computer specific options to a second screen. If you set the computer type to something other than Atari 5200 a menu option will appear allowing you to set them. All shared options (pokey type, artifact mode) are left on the main config screen.

If the computer type is set to Atari 5200 it will automatically (on exit) set the media type to cartridge and if the cart type is not 5200 specific it will bring up the cart select screen.

Changed the default cntrlr preset to "Atari Joystick". It changes to "Atari 5200" when the user selects 5200,
Atari joystick when they pick a computer (unless they use the "configure control" option). Changed autodetect to a yes/no option. Seems a little less ambiguous.

Upload configuration has been removed from the configuration screen and moved to the options screen where it makes more sense to use it.

Upload configuration adds file CRC to name. Download configuration displays current file CRC for user comparison.  More of a temporary thing until I come up with something better.
---------------------------------------

Fixed problem when a filename inside a zip contains too many characters. While I was at it I fixed the space as the last character when trimming to 42 characters behavior that has been around for who knows how long.  Zip files where the path was saved now unzip correctly.

now unloads cassette when exiting a game.  grrr.

Adventure control does not freak out and River Raid plane does not drift to the right.  Yeah!!


*** known issues ***

Some 5200 games seem to have some "drift" for a lack of a better term.

Starwars seems to be about -12 on the x&y axis.
Kaboom has about +24 on the x axis.

I believe that the computer version of Kaboom tries to take into account paddle jitter so one cannot help but
wonder if they are trying to do something here.

Pengo freaks out whenever both the x and y axis are greater than 0 (no diagonals!!). As long as you stick to
strictly cardinal directions it works fine.  (Good luck with that one).  

Emu will lock up if rewind is on and computer type is set for 130xe.  ALOT of data is being thrown around when in 130xe mode (128k+ worth) so it may not even be worth it.

[XPort]

QUOTE(madmab @ Jan 29 2008, 03:32 AM)

Wow.... just a quick glance at Vice64, Z26, and Winuaex the render_to_texture is quite different for each.  Although Winuaex seems to be the closest.  

Are they different for a reason?  Or are they just various "evolutions" of that code?  Should I look at one of the other emu sources for a transplant?  Or is the fix simpler than that?

Thanks...

The render_to_texture routine is fairly specific to each project.  It's almost always going to be different because the way the emulator stores its video in buffers is different almost every time.  


It could be the case that it starts reading from the source video buffer (what's being copied into g_pBlitBuf and d3dlr.pBits) too early - or it's reading one line of video too much.  Fiddle with the offsets of the source buffer (d3dlr.pBits is the dest buffer) in render_to_texture.  Try pushing it forward/back one line or have it not read as much - things like that.  (The filtered rendering doesn't suffer from that because those routines t "absorb" the first line in the video buffers.)

[madmab]

Hey what is the magic controller combo to activate the debug log?

I thought it had something to do with holding down left-trigger or something, but I cant seem to get that to work.

[XPort]

QUOTE(madmab @ Jan 30 2008, 09:34 AM)

Hey what is the magic controller combo to activate the debug log?

I thought it had something to do with holding down left-trigger or something, but I cant seem to get that to work.

I don't think that ever really worked - and I stopped fiddling with it when I began using the remote debugger in MSVC.

[madmab]

Well that would explain it!!!  I didn't have any luck either..  (IMG:style_emoticons/default/laugh.gif)

[madmab]

Hey X-port I was wondering if you had any insight on the playback/record stuff.  Just looking at it, it's pretty basic.  What kind of factors do you think would cause it to work incorrectly?  I know it wont work if there is no save state.  The only thing I can think of is a the emulator using a random number generator that is truly random.

Thanks

This post has been edited by madmab: Jan 31 2008, 08:01 PM

[XPort]

QUOTE(madmab @ Jan 31 2008, 02:00 PM)

Hey X-port I was wondering if you had any insight on the playback/record stuff.  Just looking at it, it's pretty basic.  What kind of factors do you think would cause it to work incorrectly?  I know it wont work if there is no save state.  The only thing I can think of is a the emulator using a random number generator that is truly random.

Thanks

It doesn't matter how "random" an emulator's number generators are - they're all going to be based on exactly the same set of parameters due to the save state.  When a save state is working correctly, it takes a snapshot of the entire virtual hardware system.  RNGs are simply calculations based on system parameters (like clock cycles since startup mixed in with values of things like the current register values and highly volatile memory locations).  Since all the parameters that it would use to generate a RNG are saved during a save-state, when the state is reloaded, you're going to have the same sequence of RNGs afterwards because it's generating them based on the same data.

That being said, the only thing that comes to mind for when the record/playback routines might malfunction is frameskip.  If there is cause for frameskip and the updateEvents function is not called when a frame is skipped, then that may cause problems.  If the save state isn't saving everything in the system, that has the potential to cause problems as well.

[madmab]

ok.  Thanks for the info!!  After digging around in the emu core code I found that an internal variable tied into the random number generation was not being stored in the save state.  Once I added it record and playback now work correctly.

I tell ya.  It sure caused some weird behavior when using the rewind function!  (IMG:style_emoticons/default/laugh.gif)  Certain events that occured alot of times would not happen again, etc.  It was one of those things that I noticed, but didn't notice.  Things are usually moving so fast it isn't always obvious.

So I can add that to my list of changes.

Record and Playback now work correctly.
Added in a do not allow activating attract mode.  Really only useful in demo's.

This post has been edited by madmab: Feb 3 2008, 12:05 PM

[madmab]

Uh oh... seems none of the analog stick movements are recorded (l/r analog stick and triggers)...  

[madmab]

Picked up myself one of these last week....    (IMG:style_emoticons/default/ohmy.gif)

(IMG:http://img175.imageshack.us/img175/9672/lightgunbg3.th.jpg)

This post has been edited by madmab: Feb 4 2008, 05:14 PM

[madmab]

Well lightgun support has been added.  Most lightgun games needs some type of custom setting since they tried to "compensate" for the lack of accuracy, or should I say resolution.  119x192.... blech..   NES definitely has it beat in this category.

Barnyard Blaster, Bug Hunt, and Crossbow play pretty well as long as you have a steady hand.  

eegt97 has been a big help getting some of the non-working 5200 games going (pengo, star trek, pitfall).  As well as giving me some ideas on getting some of the harder to control 5200 games controllable (missile command, tennis).

[madmab]

Just wanted to say thanks again to x-port for releasing the source and answering some questions for me..  

[XPort]

yw