jwierer

This one fixes a few other bugs I found. I also tried to speed it up a bit more. Animated GIFs that are sized to be 32x32 should be pretty quick to render now. ImgtoCode.zip -Jeff

Black Onyx is a great game. One of the few RPGs that I played all the way through the end. I got so far into it that I started creating maps and sort of got a little crazy and created a manual for it. Here is a copy in case anybody else would get some use from it. Black Onyx Manual.zip -Jeff

This version closes when I click from playfield to sprite. Here is a 3d fuji i made with it: fuji3d.bin Closes? I would say crashes horribly! Sorry about that. This one should work and should be faster for black and white rendered images. ImgtoCode.zip -Jeff

Here's an update. In general this should decode animated gifs faster, especially on modern computers with multiple cores. ImgtoCode.zip -Jeff

The other thing to consider is number of frames. The code it outputs won't move around banks so you could produce more data than can fit in a bank. -Jeff

Yes that is an easy change for me to make. You want to be in control of when code is actually generated correct?

See this post. -Jeff

In case anybody else wants to join in the fun, here is a copy of the utility RT has been testing for me. I am going to integrate this into visual bB, but if anybody wants to test it by itself you can give it a try. ImgToCode.zip It's written to the .NET Framework 2.0 so if you're not running XP, Vista, or Win7 you *might* need to install it from here. If you're already using Hack-o-matic 3 or Visual bB then you already have this installed and working. -Jeff

Google for "Floyd Steinberg error distribution algorithm" or "ordered dither by J.O Limb". They should give you some leads. If not I can give you the pseudo code for both. I take it that you are using the following formula to convert to greyscale? grey=0.3*R+0.59*G+0.11*B You can use integer maths without much loss (for speed) :- grey=((r<<1)+g+(g<<2)+b)>>3 Thanks. I finally did come across some Floyd Steinberg articles that were clear for me to understand and was able to implement my own library. Unfortunately, image Processing is not one of my programming strengths... [EDIT] Arnold does look better with proper dithering. TheTerminator.basterminator.bas.bin -Jeff

There are a couple of methods out there, but I created my own converter over the weekend. I am trying to implement Error Diffusion, as I have greyscale working, but it's like bashing my head into my computer to figure it out... I might just give in and use one of the open source libraries out there. BashHead.bin -Jeff

I thought it would turn out better, but now I don't know? -Jeff

For all the Schwarzenegger fans. The Terminator Original image 2600 image Source & binary terminator.basterminator.bas.bin -Jeff

I finally got around to giving this a try. A couple things that would be nice. 1. After using the command line it would be great if the program exited instead of going back to the menu 2. Is there a way to set a variable size for the width? -Jeff

The output form BMP to Atari 2600 comes very close to what you want, but is limited to a width of 40 pixels which seems like a limitation that could easily be changed. The author didn't post source, but he could probably be reached to make the change. I just gave it a shot and this is the output PF0TitleLeft .byte #%11110000 .byte #%11110000 .byte #%11110000 .byte #%11110000 .byte #%11110000 .byte #%11110000 .byte #%11110000 .byte #%11110000 .byte #%11110000 .byte #%11110000 .byte #%11110000 .byte #%11110000 .byte #%11110000 .byte #%11110000 .byte #%11110000 .byte #%11110000 .byte #%11110000 PF0TitleRight .byte #%11000000 .byte #%11110000 .byte #%11110000 .byte #%11110000 .byte #%11110000 .byte #%11110000 .byte #%11110000 .byte #%01110000 .byte #%01110000 .byte #%10010000 .byte #%11110000 .byte #%11110000 .byte #%11110000 .byte #%11110000 .byte #%11110000 .byte #%11110000 .byte #%11110000 PF1TitleLeft .byte #%11111111 .byte #%11111110 .byte #%11100000 .byte #%11111110 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 PF1TitleRight .byte #%11111111 .byte #%11010111 .byte #%11000000 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%01111111 .byte #%01111111 .byte #%11110111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 PF2TitleLeft .byte #%00000111 .byte #%00000000 .byte #%11110000 .byte #%11111110 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%01111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 PF2TitleRight .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%01111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 -Jeff

I haven't released it yet, but am getting close to being done. -Jeff

I am using batari Basic v1.01 ©2005-2007 and it is reporting (83): Error: Unknown keyword: COLUP0=68. Putting spaces between before and after the = fixes it, but then complains for all the other instances. Once those are fixed, then it doesn't like the bank statement at the end. This compiles, but just shows a circle on the screen. drop.bas -Jeff

If you're like me I like to have a physical cartridge made for hacks and homebrews that never get put onto a cart. For the 7800 enthusiasts that can be a bit challenging as custom 7800 boards are not as easily accessible compared to the 2600 and 5200 Pixels Past boards available in the Atari Age Store (when open). Fear not, for most games 32K or less it's pretty easy to hack up an existing 7800 cartridges to take an EPROM. External memory and larger roms are bit tricker, but just require you use specific games to be cannibalized for the task. Anyway, a while ago I documented my efforts to hack several carts. I believe I have posted this document in other places before, but this will make it easier to find in the future. Creating_7800_EPROM_Cart.pdf -Jeff

Just tested it out on my 7800, played a few games and it worked fine. At first I thought it was failing, but then realized it was just a simulated rack test - I like it. Are the intermissions just place holders? I heard the music and saw the sprites, but they are not animated. I couldn't tell from your post if that was intentional or not. -Jeff

I was playing with Pac Pollux and got to thinking about how the ghosts were all the same colors. Sure enough this was a hack of Bob's original Pacman hack so a quick comparison of the two in Hack-o-matic 3 exposed all the locations for the ghost colors. After that I started looking for other colors by searching for LDA, <immediate> where immediate is the color I want to find. In HOM 3 this is just a hex search for A9, and the two bit hex code. A couple hours later I had most of the color locations. I created a table for anybody else that might want to hack the various Pacman releases. After that I created a small GUI within the Pacman Construction Set to more easily set these. With this knowledge I had to create something so here is a hack I call Snow Day. It's a graphical and maze hack of Jr. Pacman. Jr. Pacman and all the ghosts are wearing santa hats and the mazes have frosted over! Instead of dots, you eat small snowballs or snowflakes? This was my attempt at a new title graphic. This is what it looks like under emulation. Notice the cliff is frosted over? Title text shadow and cliff share the white color. You can see the hats and the frosted pipes. And of course if you are interested in trying it out, here is the bin. JRPAC_78SnowDay_newmazes.bin jrpac_78snowday_newmazes.a78 *Updated* with a better santa hat. JRPAC_78SnowDay_newmazes_hat.bin jrpac_78snowday_newmazes_hat.a78

Try http://gooddealgames.com/ -Jeff

Upgrade to Hack-O-Matic 3 -Jeff

After playing upside down Ms. Pacman (see this blog post) i was a little disappointed with where the fruits would appear because they were still set to the original tunnel locations. If that locations happened to be a maze it would warp though it - awkward, but ok. If it had some empty space followed by a maze part the fruit would appear, bounce into the wall and then disappear off into space and you'd never get to eat - not the desired result. Based on some additional technical knowledge I got from Bob, I know now that Ms. Pacman and Pacman collection both contain a table of "row" locations with specify where the tunnels are in each level. The columns for these locations are actually shared for the entire game so a change there would mean all levels would need to conform to that change. Because it's just easier to use coumns 0 and 27, I used as fixed columns that can hold the tunnel locations. It's now possible to set fruit start and end locations in my Pac-man editor! You can actually change the pattern that the fruit takes, but for the sake of my purposes that is a bit more involved than is necessary Now the fruit locations are correct for my upsidedown Ms. Pacman While I am at it, it was pretty easy to create an upside down version of Pacman. While I was at it I corrected the dot color. The arcade is actually slightly peach colored, not white! and for anybody interested in trying these out here are the binaries upsidedownMsPac.bin UpsideDownPacman.bin -Jeff

<Rant on> I'm annoyed for two main reasons :- 1) You didn't ask me privately. Even if you did ask I'd still have said no because the level editor I use is called Tile Studio and its something I've used for years, so I know all its quirks and I'm comfortable with it. You could have saved yourself time and effort. 2) This is a "live" game development. With Apple Snaffle being a new homebrew game I would not expect somebody to just come along and rip the sprites and level data while it's still a WIP. That's a big "[email protected]#K YOU" slap in my face for taking time out to support a long dead games platform. I'm no "wet behind the ears" programmer, if I can't do something or I'm stuck I'll ask. <Rant off> Saw "level design contest" and got excited. Definitely not my intention so please accept my apology. -Jeff

Thanks for annoying me this morning! You could of at least PM'd me first if you could extract the level data. Makes me just want to wait and release the final version on cart now. Wow, didn't mean to annoy. Don't worry I won't post an editor. If you want it for your personal use, PM me. -Jeff

I was wondering what the game play of Ms. Pac-man would be if the mazes were flipped. So I started recreating the mazes, but that seemed ridiculous tedious so I added a new feature to my Pac-man editor that would allow you to flip items vertically and horizontally. With that I was able to flip each of the mazes, all the graphics and the title screen. Came across a couple issues when creating this. Ghost Pen: The Ghost pen isn't really located in the center of the maze and it can't be moved so when you flip a maze you don't exactly get the same maze upside down Fruit Locations: The fruits still enter the maze at the original tunnel locations. This adds the effect of the fruits materializing through the walls. I am sure there is a table with fruit generation locations, but I haven't found it. Dots: Flipping the maze generally works, but in the editor the dots get all messed up so the best way is to clear the dots and add them back after the maze is modified Title: The title has shared blocks of pixels so it's not possible to exactly flip the title. If you look closely a few pixels are off. Anyway here is a screen shot of the title and of the 2nd screen (notice the fruit location). And here is the rom if you want to try it. Game play is very different from the original upsidedownMsPac.bin