R0ger

More like by the original: http://handheldempire.com/game.jsp?game=789 I guess people outside Eastern Europe wouldn't know them :-)

We released small demo on Forever, and due to lack of serious competition we happened to win ! It's basically result of experimenting with some algorithms for road drawing. Olomouc skyline GFX is done by PG, the music is by Hardcore, the code and the rest of the GFX is by me. This version is updated with NTSC support. It fixes the color differences and music speed. It runs at 50fps on PAL and 60fps on NTSC, with no compromises. There is just some reserve on PAL. Enjoy ! road.xex

Guys, guys .. give me one more day to add NTSC support .. meanwhile enjoy the video .. Also any idea how to prevent modern TVs to show things outside the normal overscan areas ?

Why not both ?

No idea where 72 came from. It's 114 cycles. And on Atari you need at least 9 every line for memory refresh (including vblank).

Thanks for clearing thing up, Xuel !

Yes, but this clearly does not use IDE. So this is emulation only ? Even that might be interesting for testing some ideas ..

How is it done ? I have some ideas about converting video, but I don't know how to load it from XEX fast enough. I know about that SIDE player, but that only works with SIDE, right ?

Nice little thing indeed.

I don't even recall game which would need autofire ..

That's my opinion too. Pot is the way to go imho. I also like the option to use one button as 'up'. So I'm thinking about 3 position switch - normal / up / pot. Keyboard can't read 2 keys at once. It can read shift independently. So if you have games that only uses left, right and jump, like Manic Miner, it can be done. But not in general. Another option is to simply define 8 keys for 8 directions. Karateka uses something like that.

That's just aliasing. You have to stretch lets say 400 lines with scanlines into lets say 768 pixels. That will give decimal ratio. So some lines will be thicker, and some will be thinner. It can be fixed by setting stretch mode (menu view) to one of the integer options. That will make the image smaller, but will use same pixel size for every line.

Hm, doesn't it take full frame to read paddles ?

I had this one too. And it's certainly weird you don't have that issue. I won't be able to test it anytime soon, will report when it happens.

It was some cheap Chinese stuff. 3 buttons only. Don't remember the numbers. My code took the starting value as not pressed, and any change as pressed. I wanted to support both types of logic. High value for pressed and low value for pressed. But if it behaved same as you setup, it would be great, the logic would be simpler.

Btw. I have found during my test with SEGA controllers, that there is typically transitional value in between 'off' and 'on' state. It's logical, the paddle sums the value over the whole frame, so if you press the button just before the paddle reset, you wont get 1. You get that next frame. So in my tests I treated any value different from the base value as 'pressed'. Have you encountered something like this ?

I see. Good job !

Why the resistors ? And what values can you expect on the paddles ?

That's the thing. It seems he didn't. He's just saying he's not sure it's gonna get released at all, and that he will remove the link if people don't like it. And the author is famously hard to get into contact with.

I'm not big fan of modding somebody else's game. I mean if it's abandonware, sure. But WIP, few months old ?

Some basic dumping / disassembly is part of QMEG, right ?

Isn't that exactly why flickering isn't a problem anymore ?

Why monitor on real hardware ? Emulators are way better, and have functions like this. And functions simply impossible on real hardware. I use Altirra for everything.

It's also on Fandal's site .. as (almost) everything .. http://a8.fandal.cz/detail.php?files_id=7432

Also please note the games in Pseudografx's signature, he's too shy to point them out, and there are some ABBUC winner in there ..