kingofcrusher

Nice, I love Pang. Played and beat every version of it ever!

If you hit Alt + Enter (at least on PC, I think it's the same on Mac) it'll stay windowed but use the entire window for the game screen, and from there you can hit ESC to toggle between full-screen and windowed like evg2000 said. The Mac version only runs well in full-screen mode (either full-screen windowed within Meka or actual full-screen) though, for some reason it doesn't update correctly all the time when in windowed (within Meka windowed mode I mean). I think Brock is working on it for the next update, but it's a minor problem unless you're using the debugger (and even then it's only just slightly annoying sometimes). It runs perfectly when full-screen so it's fine for playing games, but if you're just gonna play Coleco games I'd use MugRat instead since it seems to be flawless as far as I can tell. The debugger in Meka will make your life infinitely easier though, it's amazing.

objcopy.zip Oh yeah, I almost forgot, you need objcopy in the same folder as your source files or the makefile won't work. I'll attach that to this post.

Use Xcode (best developer environment of all time) with SDCC installed, http://sdcc.sourceforge.net/ Also, download Daniel Bienvenu's windows C package from this forum, his library files are invaluable even if you don't use them directly and just reference them on how to get a game up and running in C. I couldn't have gotten started without his amazingly helpful work. Finally, use a makefile like this in Xcode (probably not the most elegant makefile, but it works for me just fine) and you can build just like any other Xcode project- To debug I took the Mac Meka port and made an .app out of it so you don't have to install allegro- http://www.smspower.org/forums/viewtopic.php?t=13308 it's around the middle of the posts, the file you want is MekaOSX.dmg (2.38 MB). Meka has the best debugger I've ever seen, it'll seriously make your life 100 times easier. You can watch RAM, VRAM, and registers all in real time.

As a programmer I can say unless you're paying a decent amount of money no one is going to be interested. Ideas are basically worthless since the person doing the bulk of the work (i.e., the programmer) generally already has a billion ideas for games that they can draw from, so unless you're paying them it's just never going to be worth their time. Really the only way is to learn to program and just do your idea yourself, unfortunately.

How does the Colecovision display 128 colors? Uh, dithering? Hah.

You can easily say that "on paper" one system should be more powerful than the other, for example the PC Engine versus the SNES; PC Engine on paper looks basically like a really beefy NES, but if you look at the library there are games that match the best SNES and Genesis visuals of the era. So technically the SNES would be a "more powerful" system, but it had a shit-slow, half-retarded CPU that held it back. In reality there's just too many factors involved to give a definitive answer unless one vastly outstrips the other in all regards (i.e. Coleco VS Atari 2600).

For the 5 games I released so far, sales were in the 58 to 92 range. Philipp I was curious if any of the publishers have tried using ebay to increase sales? It always seems like you see games start cropping up on ebay relatively shortly after they come out (Pier Solar for example) and sell for way more than the original price. It seems like it might be worthwhile to print up an extra batch of copies and open an Ebay store to sell them through, but I could be wrong (obviously small publishers have probably tried this already). Probably for the amount of profit they make it just isn't worth the time to deal with ebay fees, retarded ebay users, selling one at a time, etc.

Hah yeah, that's how Pitfall 2 was. Stupid VDP writes all over the place with DI/EI scattered everywhere. Plus the game used about 99.9% of the rom space so there was very little to work with. Fortunately I was able to use an MSX compression scheme I found to compress most of the graphics and free up a lot of space along with axing all the stupid keyboard input code. Thank God too because I needed every available byte to get things working, I think I had like 10 free bytes when it was finished, haha.

Thanks again, Coleco, for that brilliant bit of engineering. Haha! I owe you a big thanks; I studied how you dealt with the NMI in your source code for Black Onyx, without that knowledge I probably would never have forged ahead with the conversion out of sheer frustration at how stupid that feature is.

No, the Pitfall II bug is due to the NMI on the Coleco. It wouldn't happen on the SG-1000 because you can mask the interrupt. I couldn't fix it without breaking other things unfortunately.

Silpheed on Sega CD uses polygons for enemies, you can enable the debug menu and rotate the enemies on their axes.

Why won't the Coleco recognize button 2 when you're pressing diagonal up/left? I've tried using both my own input routine and the Coleco bios routine and neither will poll button 2 when UP and LEFT are held. I've even watched a few commercial game's RAM addresses where they hold the button press and it won't work either which leads me to believe this is some issue with the Coleco.

Awesome, I've been curious about that for a while since the limit is so severe. Thanks! I take a lot of time doing the art to make sure it fits in the 256 tiles. I use the extra VRAM space to decompress nearly everything to so the trade-off is well worth it.

Ah that might work, each map could just have a bitmap for paths sprites can take. On the sprites, I'm retarded, I just remembered the bit flag gives you the number of the fifth sprite, hah. How many sprites can you get on a line before the flickering becomes too much? I haven't experimented yet, but it seems like you could have at least 6 without it being too bad, but then I haven't tried it yet so I'm probably wrong.

Couple questions for the programmers out there- How do you guys generally handle AI routines for enemies? I'm thinking of setting up simple X1 and X2 boundaries for each enemy and then just having them run back and forth until the player is on the same X, at which point they attempt to attack the player. I'd really like to implement some rudimentary pathfinding though so they can move around and chase the player, but I can't think of any simple way to do it that doesn't require a ton of code. Also, the 5th sprite thing, do you guys just check every NMI for the 5th sprite flag and then figure out which sprites are on the same X by comparing all the X coordinates of sprites on screen, or is there a faster way where you don't have to do comparisons for them all? I don't like using the Coleco bios routines because they take way too long and they always destroy all your registers.

Haha, thanks. Yeah I'm excited about Pitfall 2, I put a lot of work into it although I think it would have been easier and less time consuming to just code the game from scratch, hah. I'm very proud of the results though and very thankful Luc gave me the opportunity and motivation to do the game.

Well since I just finished up (finger crossed for no further bugs) Pitfall 2 for Pixelboy I figured I would make a topic for my two projects since I can devote all my spare time to them now. The first is the raycaster game I've been working on (titled Gestalt), I haven't updated the video yet so I won't bother linking to the old one. The second is a side-scrolling action/adventure game titled Radiant: I Will Murder Your God which I put a very early video up of the first screen just to show some basic interaction- http://www.youtube.com/watch?v=5x51y_83pjI Anyway the programming isn't time-consuming, but designing is taking much longer than I anticipated. I hope to have one of them out by the end of the year with the other shortly following. I'll post up new vids as I hit milestones for anyone who is interested.

Have any of you guys done a port from MSX to Coleco yet? Assuming the game only uses 1k RAM (or can be modified to only use 1k), what are the hurdles? I was looking at the MSX and it appears to have a ton of built in bios routines like the Coleco, so I assume getting around those is the first major problem. Any specific advice for someone who is dabbling in it?

Awesome, thanks for the tip, that should make a big difference. I hadn't even thought about that, but after researching how some other people did raycasters on old systems I saw double buffering come up alot. Right now though I'm using VRAM for decompression of the maps so I'll have to move some stuff around, but that should work great. Starting another thread is not a bad idea, I have a few questions that you guys could help me with since obviously you all know the VDP WAY better than I do.

It's entirely in assembly:-) I'm curious about what you mean by switching pattern tables, is that what double buffering is? I hadn't thought of that-- that would remove the annoying wave as the screen updates. I have a section of VRAM dedicated to the viewing window, so basically the way it's working is it clears 64 bytes of RAM for an 8 tile column (it was 11 tiles, but this way I only have to write color to one color table instead of 2 which means I can actually add color back in), then scales one slice of the texture to the lower nibbles of each tile, then on the next angle pass it scales to the upper nibbles and then ORs each nibble with the other. Every two passes it writes the full tile column to VRAM. I'd love to be able to hold the entire screen in RAM then just do one huge update, but the Coleco only has 1k so that's out, I can fit at most 2 tile columns at once in RAM without sacrificing other areas of the game.

Thank you for the kind words. It switches to third-person just so I can test that engine, normally that would be reserved for special rooms and things like that. Since the viewing window is so small I decided some overhead parts would be a good way to break things up and allow for different puzzles. The health for body parts will affect things exactly like you say, severe head wounds will cause death, but other injuries will affect other things (like walking speed, attack strength, etc).

Here's a new video of what I'm working on. Everything is still early so I haven't polished anything up, and the battle engine will obviously incorporate melee weapons of some sort when I'm finished. Also it's going to be sci-fi, not medieval, the medieval graphics are just holdovers from an earlier build. I really wish the stupid VDP wasn't so slow, the raycasting would run relatively fast if it wasn't for that. I'm trying to devise a way to reduce the amount of writes required each update, but so far nothing has worked. http://www.youtube.com/watch?v=KxO5yePdH4E

I just use a bit flag that's always at $7000 for any routines that write to VRAM so you can test BIT X, (IY+$00) without having to load anything. The NMI does an EX AF, AF' to preserve flags then checks the flag, if it's set it jumps to the end. After the VRAM write you remove the flag and do a IN A, (BF) to acknowledge the interrupt. That cleared up all my VRAM corruption problems. I used a MSX decompression routine and had to use this method or half the time it would decompress garbage data since it would get interrupted in the middle of writes by the NMI.

Oh cool, thanks! I'll upload a new video once I get some bugs ironed out. I have to finish Pitfall 2 first, but after that I'll have plenty of time. The next will show the overhead view mode and the battle system. Also, thanks for all the music you post on here, I modified one of yours for the opening song because I couldn't figure out how to do drums. I changed all the melodies and bass, but the beat is the same.