Hmm, Is there a better (free) place I could host the prg images I wonder?orion70 wrote:Damn! I can't download stuff from Google here at work
That was the only place I could think of that I had an account on.
Moderator: Moderators
Hmm, Is there a better (free) place I could host the prg images I wonder?orion70 wrote:Damn! I can't download stuff from Google here at work
Ya, the worst is if there is a 'blue' ready to eat ghost sitting on top of a dangerous ghost -- you can get caught by surprise.orion70 wrote:No better place, don't worry. I only had to wait a few hours, and now I'm enjoying this game, impressively similar to the original.
I particularly liked the sounds and the overall smoothness. If I can be the only one to complain about a minor defect, color clash is quite visible compared to other clones (please guys, ignore the last phrase).
To avoid color clashes you need to go to the "Atari 2600"-style of coding called "Racing the beam" - meaning you will have to update the picture as it is being drawn. This way you can switch colors for each rasterline and avoid vertical (y-axis) color-clashes. Way harder are horizontal (x-axis) raster-splits as they require absolute exact timing. Victragic was crazy enough to try this in his Pitfall-clone and succeeded brilliantlybills442 wrote:I've been fascinated by some of the really amazing advanced techniques guys use on here for extending the color capabilities of the vic. I would like to try them out someday in a future attempt.
Was this the 8k version or the 3k? I have to say the 8k has gotten almost no testing; although it's just a re-assembly of the 3k code to load into 8k so I'm hoping that wouldn't introduce any bugs. I did take the 3K version to a little 'retro game' party last weekend and it ran for about 4 hours on a real vic with seemingly no problems. I was surprised nothing bad happened -- if not in the software then I was even worried the old hardware might have gotten hot and flipped a bit or something.beamrider wrote:I've just tried playing this on real hardware and it looks really nice.
I did spot a few little bugs however...
1) At one stage there were about three additional copies of pacman below the cage. I went to get my phone to make a video but it didn't re-occur.
2) I did also notice that sometimes pacman seem to get a sudden burst of extra speed, but this doesn't unduly affect the game
3) When being chased through the tunnel pacman seems to reappear instantly on the other side of the screen, but the ghosts take longer.
Nothing major though and again plays really nicely on real hardware.
Ok, well I just played the game in WinVice with my machine set to be like PAL ( which I assume your vic is? ) and pacman speed seems all goofy, he kinda jumps and bobs. Something is different but I have no idea what!? Let me see if I can figure out why that would be. Would you be willing to try the game in Winvice set up as NTSC and see if the pacman speed issue is gone?beamrider wrote:It was the 8K version.
Oh ok, perhaps the tunnel behaviour is "as designed" then. Not sure, just to me seemed a little different to the arcade to me, but I could well be wrong.
I got the impression that pac-man moved a little faster sometimes because the load on the game had "reduced" and it was able to occasionally get in more game updates per frame? - again could be wrong....
Cheers
Adrian
beamrider wrote:Yes, it was a PAL vic and yes it does play better under the Vice on NTSC.
I always found it difficult to keep a game running at a constant speed on a machine like the vic with minimum grunt. I found that you need to limit the number of game updates per screen refresh to get a constant speed but this does means you're wasting some of the CPU.
But then it might run too fast, and you'd be wishing for more resolution. And if you had more resolution, you need more memory. With that, wouldn't it be great to use multicolor? Oh, that requires masking, so it takes more CPU cycles. Drat, it lost frame rates, I wish I could get it to run at 100% all the time.bills442 wrote:I wish I could get it to run at 100% all the time
OT: yes, the programmer has the option to update the pending frame, paced by the machine's refresh (calibrated with the IRQ handler for accounting accuracy, but offers little in terms of video effect). The IRQ handler does not do the dirty deed itself, it is governed and under control of the main program / loop.beamrider wrote:... enters a wait loop inside the SSSFLIP