New interpretation of Pitfall! for PAL Vic + 16K

Victragic · Post by **Victragic** » Tue Sep 03, 2013 7:36 pm

Any particular reason why you changed the music for the vines and player death?

No real reason - coding music is not my thing, really. The theme for swinging on the vine is the start of the theme music in Pitfall 2 instead of the tarzan call. The death theme was meant to sound like a 'sarcastic' version of that.

I had thought the three or four-part Pitfall 2 theme would be good to use - but as I said, coding music is not my thing. There's probably just enough memory and raster time to do that, but my efforts sounded woeful. If someone wanted to code a killer version of that theme, all credit would be given.

..speaking of which, I've noticed a lot of recent Vic releases have a nice hi-res loader screen. Does anyone want to code one? Credits given as well, would make it seem a complete project with these two improvements.

(A couple of fixes before calling this a 'release' then, let's call this the beta version.)

Mayhem · Post by **Mayhem** » Wed Sep 04, 2013 2:52 am

Yes, in the original 2600 Pitfall, you travel three screens when underground, and is the only way you can get round the whole map in time to collect the treasures.

orion70 · Post by **orion70** » Wed Sep 04, 2013 2:57 am

See also the suggestions in the map I linked

Victragic - I think your game once finished deserves to be submitted to Psytronik for a commercial release (if there are no copyright issues with Activision of course - but a modified name like "VIC Jungle" or something would suffice).

Ghislain · Post by **Ghislain** » Wed Sep 04, 2013 8:37 am

orion70 wrote:See also the suggestions in the map I linked

Victragic - I think your game once finished deserves to be submitted to Psytronik for a commercial release (if there are no copyright issues with Activision of course - but a modified name like "VIC Jungle" or something would suffice).

I agree. I think more people from here should submit their stuff to Psytronik. Even better, just include several games from their own "VICography" in said package to sweeten the pot, so to speak. You can fit a lot on a floppy disk or D64 image.

Mike · Post by **Mike** » Wed Sep 04, 2013 3:08 pm

Victragic wrote:[...] speaking of which, I've noticed a lot of recent Vic releases have a nice hi-res loader screen. Does anyone want to code one?

Well, even a raw convert of the Intellivision game box into 104x256 FLI already would look like this:

IMO, this graphics mode nicely matches up to the display routine used in your game.

Had no idea, and again, really wish I had the real hardware to develop this on.

It's not strictly an emulator issue per se, you run into the same problem with real hardware, if you got into the bad habit of loading everything ',8,1'.

Besides changing the load address to $1201, thus omitting the 0 byte at $1200 (the BASIC interpreter automatically initialises this address on start-up, BTW), you could use the line number to indicate the release year, and add a blank after the SYS so the line reads like this:

Code: Select all

2013 SYS 8192

Victragic · Post by **Victragic** » Wed Sep 04, 2013 6:34 pm

Mike, that image is exactly the sort of thing I was hoping for

I could argue that starting the game at $1200 instead of $1201 was being thrifty, but in truth it's due to my Commodore 64 days - load"*",8,1 for everything..

As for commercial release - would be nice, but raises an issue for me. This is David Crane's game, I coded it as an attempt to follow his experience.. which gave me great satisfaction. I spend countless hours 'racing the beam', trying to fit all the operations in the allotted number of system cycles, and coming up with ways to solve problems with the hardware restrictions I had set myself. It has given me immense enjoyment, but it's still not my game.

There is a major bug I hadn't noticed - the treasures don't reset on restarting the game!

Will code bug fixes and enhancements soon..

orion70 · Post by **orion70** » Thu Sep 05, 2013 12:52 am

Thank you again

. Too bad it won't become a jewel-case disk with the intrepid adventurer on the cover. If you followed D. Crane's code, I guess the game screens and objects are exactly the same? One more silly question: I noticed that the stairs are thinner in the original version of the game... is there a reason why in this VIC version they are wider? (not saying that you should modify them of course!)

English Invader · Post by **English Invader** » Thu Sep 05, 2013 2:54 am

Victragic wrote:As for commercial release - would be nice, but raises an issue for me. This is David Crane's game, I coded it as an attempt to follow his experience.. which gave me great satisfaction. I spend countless hours 'racing the beam', trying to fit all the operations in the allotted number of system cycles, and coming up with ways to solve problems with the hardware restrictions I had set myself. It has given me immense enjoyment, but it's still not my game.

I've mentioned this before, but there is a relevant precedent over at AtariAge. Someone was working on a port of Pitfall! for the Lynx and DC actually posted on the thread and said that although he didn't have a problem with people porting his games it was Activision who had the final say and they have a legal obligation to pursue any copyright infringement (whether it affects their financial interests or not) or they forefeit the right to further legal protection in the future.

Mike · Post by **Mike** » Thu Sep 05, 2013 10:51 am

orion70 wrote:I noticed that the stairs are thinner in the original version of the game... is there a reason why in this VIC version they are wider? (not saying that you should modify them of course!)

It's a quite simple reason. Many screen elements you are looking at in this implementation of Pitfall do not exist at all.

I'm serious.

The orange tree trunks against the light green forest, the (changing) pits and ponds, the small pits, the floor(s) and the ladder are drawn by changing the background colour register of the VIC chip alone, as the electron beam traces the screen. The fastest rate at which this can be done is every 4 CPU cycles, which corresponds to a width of 2 characters, or 16 pixels. This is the lower horizontal size limit of this kind of objects. Though they can be shifted in whole to the left or right in 1 cycle steps, i.e. 4 pixels.

...

Speaking of which, I'd like to ask whether it might be feasible to change the jump width a bit. At the moment it looks like it is ~18 pixels, which allows to jump across the smaller pits (albeit barely), but gives a lot of problems when jumping over the crocodiles. Even though one can stand on their heads when their mouth is open, after a jump you come out 'misaligned'. Is that the same behaviour on a 2600? Maybe it would be nice, if the jump width could be set to 16 pixels instead, with an extra pixel of tolerance allowed at both sides of the small pits (after all, you still stand with one foot on the edge

).

On real hardware, changes of the background register happen one pixel late with regard to (half-)character boundaries. Newer versions of VICE honour this, did you also take this into account for the 'collision' detection?

I could argue that starting the game at $1200 instead of $1201 was being thrifty, but in truth it's due to my Commodore 64 days - load"*",8,1 for everything..

When the directory is loaded this way, on a C64, it is written to the screen. That might have served as clue that something might be wrong with 'loading everything with ,8,1'.

Mike, that image is exactly the sort of thing I was hoping for

The caption, the green border and some other parts of the picture could be tidied up a bit, though. I'll have a look into this over the next days.

Boray · Post by **Boray** » Thu Sep 05, 2013 12:53 pm

Mike wrote: Many screen elements you are looking at in this implementation of Pitfall do not exist at all.

While for example the ships in Omega Race exists for real! Somewhere, in the omegan system.

RJBowman · Post by **RJBowman** » Thu Sep 05, 2013 2:20 pm

Mike wrote:
orion70 wrote:I noticed that the stairs are thinner in the original version of the game... is there a reason why in this VIC version they are wider? (not saying that you should modify them of course!)
It's a quite simple reason. Many screen elements you are looking at in this implementation of Pitfall do not exist at all.

I'm serious.

The orange tree trunks against the light green forest, the (changing) pits and ponds, the small pits, the floor(s) and the ladder are drawn by changing the background colour register of the VIC chip alone, as the electron beam traces the screen. The fastest rate at which this can be done is every 4 CPU cycles, which corresponds to a width of 2 characters, or 16 pixels. This is the lower horizontal size limit of this kind of objects. Though they can be shifted in whole to the left or right in 1 cycle steps, i.e. 4 pixels.

This seems like a more difficult solution that is necessary. Why did you decide to do it this way?

Mike · Post by **Mike** » Thu Sep 05, 2013 2:44 pm

RJBowman wrote:This seems like a more difficult solution that is necessary. Why did you decide to do it this way?

I didn't write the game, but I'll answer your question nonetheless: because it allows to have a multi-coloured player 'sprite' in high-resolution that doesn't colour clash in any way with the background.

Besides the in-line splits of the background colour, the foreground colours of two adjacent player characters, as well as the foreground colour at the position of the enemies on the right hand side are changed on a per-line fashion. This allows for a discernible hat, face, (striped) jacket and trousers of the player, and the distinctive look of the snake; it is also possible to shift up and down the colour pattern together with the player 'sprite' with pixel accuracy (and not only in 8 pixel steps).

tlr's fcbpaint gives a good example where in-line splits of VIC colour registers are freely placeable on the screen to increase the colour resolution (with 4 pixel tall colour attributes), and the FLI modes pioneered by Torsten and me allow for screen wide 8x1 pixel colour RAM attributes combined with new background/border/auxiliary colour each raster. It's just the graphics mode of fcbpaint only allows for static images, and screen updates with the FLI modes (while the display is active) are rather slow and not really suited for animations.

This version of Pitfall really shines, because it utilizes both in-line splits and dynamic colour RAM updates for an FLI effect - together with smooth animation! Of course, it took a specialized display routine to achieve this feat.

From a technical point of view, to say this is bleeding edge really is an understatement. It is more like a shot across the bows directed at the so-called 'demo sceners'.

Victragic · Post by **Victragic** » Thu Sep 05, 2013 5:43 pm

I knew Mike would know what was happening right away.

Btw, yes - the game takes into account the one bit screen displacement.. otherwise I could have used character masking and raster shifting to hide the edges of the ladder to make it look thinner. Was disappointed I couldn't do this.

There are parallels between this game and the graphics modes that Mike and Tokra have been developing, I wanted to show that it is feasible to create a reasonable game on the Vic using similar raster effects, and hopefully inspire other programmers to try similar techniques.

tokra · Post by **tokra** » Sat Sep 07, 2013 3:10 am

Mike wrote:Speaking of which, I'd like to ask whether it might be feasible to change the jump width a bit. At the moment it looks like it is ~18 pixels, which allows to jump across the smaller pits (albeit barely), but gives a lot of problems when jumping over the crocodiles. Even though one can stand on their heads when their mouth is open, after a jump you come out 'misaligned'. Is that the same behaviour on a 2600? Maybe it would be nice, if the jump width could be set to 16 pixels instead, with an extra pixel of tolerance allowed at both sides of the small pits (after all, you still stand with one foot on the edge ).

After playing the game for some time and comparing to the Atari-version I agree with Mike on this one. On the original you can jump over all 3 crocs in one go. In this version the crocs are VERY difficult to manage, to the point of making it annoying. If there is a way to make this easier, maybe as Mike suggested, this would really help playability.

Also I noticed that the jumps over the small pits need to be timed much more accurately than on the original. I realize they must look wider on the VIC due to the technical constraints, but maybe extra tolerance when jumping over those is possible as well?

orion70 · Post by **orion70** » Sat Sep 07, 2013 5:22 am

Hey guys, you're starting to ask for cheat modes

Victragic wrote: spend countless hours 'racing the beam', trying to fit all the operations in the allotted number of system cycles, and coming up with ways to solve problems with the hardware restrictions I had set myself.