Jump to content
IGNORED

Miniature Golf course editor


tremoloman2006

Recommended Posts

Wow... what a cool website! Thank you for this!

 

Is there any way to make this save a hacked level to any other than level 1? I guess I need more smarts than using the editor by itself. :)

 

Again, thank you!!!

No problem!

I haven't tried myself but i think the best way would be to change the playfields with Bit Hacker.

In the Readme file is an example how to display the title-screen of E.T., this should also be doable for Miniature Golf...

Link to comment
Share on other sites

  • 1 year later...

IMO it would be better to expand upon the kernel, rather than use the same old GFX hack method. It's very easy to alter the kernel -very- slightly so that you don't have to be stuck with 5 bands of GFX at the same intervals for every hole...and also add stuff like playfield control into the data (so you can use mixes of reflected and mirrored data, similar to what has been done with Adventure). Also, the game is limited to 9 holes, but changing 1 variable's maximum amount lets you get around that without any tricks. Advanced gameplay like an optional moving hole, diagonal moving obstacle, etc. are very also easy to add.

 

Interested?

 

Here's a straight disassembly that shows where the screen GFX and sprite X/Y exist in the original game for the 9 holes, for easy editing. I've killed the visible HMOVE from the display...and added a PAL60 option (with the adjusted color values).

 

BTW you gain another 2k of ROM just by moving the last 4 bytes, so there is plenty of space for expansion. The game does not use indirect-addressing at all, so it's fairly simple for anyone to edit. Almost as easy as using a screen editor GUI.

MiniGolf.zip

Link to comment
Share on other sites

CTRLPF added. This sample was produced just by altering $F73D to use mirrored GFX instead (and setting the high bit so the border is shown on both sides).

Now I'll work on variable band resolution.

 

Something interesting is that the moving obstacle is saved to an 8-bit sprite. So is the cup. It should be possible to turn it into something else, and have a hole-shaped cup. It looks like there's enough unused cycles there.

post-222-1237685527_thumb.jpg

Link to comment
Share on other sites

Current developments:

The cup is round.

 

The moving obstacle can be any 8-bit shape. You can even have differing obstacle shapes for each hole, and they can be any length up to 256 bytes. The delimiter can be any value you choose, so the shape can contain imbedded zeros as well.

 

Variable linecounts are in place...you can have as many groups of PF data as you want - with a limitation. The screen gfx for any given hole must not cross a page boundry, and the cup must not begin on a scanline that's due to update playfield gfx. Not much of a limitation, since no screen should require more than 256 bytes of data (that's 64 groups of PF data!), and identical line numbers are easily avoided for drawing the cup.

 

Shape and screen definitions can exist anywhere in ROM (as opposed to being located on a single page for all of them).

 

Now working on adding some more stuff :)

 

The new screen gfx layout looks like this:

Hole1: ;PF0 w/CTRL, PF1, PF2, scanline# to move to next group of data (end w/zero)
      .byte %11110001,%11111111,%11111111,$55 ; XXXXXXXXXXXXXXXXXXXXRRRRRRRRRRRRRRRRRRRR
      .byte %00010001,%00000000,%00000000,$3F ; X                                      R
      .byte %00010001,%01100110,%00001111,$2A ; X    XX  XX XXXX        RRRR RR  RR    R
      .byte %00010001,%00000000,%10001111,$14 ; X           XXXX   XR   RRRR           R
      .byte %00010001,%00000000,%11111111,$02 ; X           XXXXXXXXRRRRRRRR           R
      .byte %11110001,%11111111,%11111111,$00 ; XXXXXXXXXXXXXXXXXXXXRRRRRRRRRRRRRRRRRRRR

 

Bit4 of PF0 is automatically set...so the edge border is drawn regardless if the data is ®eversed or (M)irrored. The low nybble is used for CTRLPF to set display mode and priority for the three PF values. The last value instructs when to use the next group of data, so you don't even need to calculate the total number of lines when creating screens. Just give it a lower number than the one before it, and off you go.

Link to comment
Share on other sites

Variable linecounts are in place...you can have as many groups of PF data as you want - with a limitation. The screen gfx for any given hole must not cross a page boundry, and the cup must not begin on a scanline that's due to update playfield gfx. Not much of a limitation, since no screen should require more than 256 bytes of data (that's 64 groups of PF data!), and identical line numbers are easily avoided for drawing the cup.

Hmm, let's see, 2048 bytes divided by 9 holes equals 227 bytes per hole. I can live with that. :)

 

Cool, I see you've added a 4k version!

Edited by accousticguitar
Link to comment
Share on other sites

Hmm, let's see, 2048 bytes divided by 9 holes equals 227 bytes per hole.

 

That's if you wanted 9 holes. It's easy to increase the number, for example, if you wanted different "coarses" to play on that could be selected by the console switches.

 

Anyway, there still are a couple of unresolved things (which is probably what you ran into). The color/bit test tables absolutely positively needs to begin at address $xxAD...not sure why yet. And data is shared in the original game's screens (that's why all of the PF0 lines begin with $FF).

Link to comment
Share on other sites

That bit table is still unresolved if you want to use the current version. I just stuck it on the last page. Also, there's unused space on all of the pages that I used. Screen and object data are on their own pages, but don't need to be (because full indirect,y vectors are now used for both). You can make some really detailed screens and really tall objects...however objects currently are not drawn "intelligently". When moving vertically, they will blink into existance when their top scanline can be drawn on the upper line...and lose whatever falls into the lower border.

Link to comment
Share on other sites

That's weird, I tried out your 4k version in Z26 and it made the same noise, so I loaded them both onto my Kroc cart and they seem to work fine on hardware. Maybe my 4k version is okay after all (other than the hole in the middle of the playfield wall on the second hole of the course so I can't proceed beyond that point in the game). :D

Link to comment
Share on other sites

Yeah, I was just stuffing other things in there that were already disassembled to make the obstacle different on each hole.

 

Moving cup added. If you want to put this in the previous file, copy/paste the entire upper portion (all equates and program instructions), and also table LF6DB. Just as with the moving obstacle, when Xmin = Xmax there is no horizontal motion. A new check is that when Ymin = Ymax, there is no vertical motion if those values are not $FF. This works for the obstacle as well (if you want it non-moving).

 

Nearly half of ram is still unused. It might be possible to include shifting playfields for screens that are not too complex :)

4kMnGolf.zip

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...