tabachanker2

Youki: OK, thanks for the precision. And it's not something you said specifically, it's just your whole insistence of "I know I can get it to run under 1k RAM" without even knowing the insides and out of the game. I've been working on the game for almost 4 years (on and off admitedly), that's why I am positive it can't be done. I could tell everybody that I can do the last, I don't know, Fire Emblem on the Coleco with only 1k RAM, but I would be wrong. Kiwi: Yeah the cart resides at the normal $0000-$7FFF. Then it uses the normal 1k SG-1000 RAM at $E000-$E3FF for the stack, music routines and decoded demo movements, then it uses an extra 8k RAM at $8000-$9FFF for evrything else (including what I already wrote in this thread). It doesn't use the whole 8k, just shy of 4k really. That's why at first I was like Youki and thought I could optimize it in less than 1k. But I came to the conclusion that the game would have to be severly cut to to do it.

I'm glad to hear that wasn't your intention. But you come into my new game offical announcement thread and start discrediting it by saying : all the while spouting false claims like the SG-1000 version does not use more than 1k RAM and that I've ported the msx version of the game. Then you try to win an argument without all the knowledge beforehand, saying essentially: "I could do better than you".

Yeah,yeah, that's what I though at first too... The game engine is made with expandability in mind. That's why there are 2 games with 2 different castles. I could make a 3rd game with a new castle just by changing the game data. Even if you save some bits per room because not all rooms have the maximum objects, you would still need to add a few tables to keep track of everything (room 1 has 2 doors, 3 enemies, 4 collectibles, etc.) And there are rooms with near the maximum objects. There's a room with 8 enemies, there's a room with 12 blocks (they can be crushed by the way and they do not respawn... an integral part of some puzzles). There's a couple rooms with 12 collectibles. I could have shove a few bits with the doors I admit. But then what... There's still all the other RAM used by the game. Plus, if you decide to use dynamic amount of bits per rooms for each objects, you have to keep a pointer tables for each rooms, which doesn't help with the space available. And it breaks the game engine as you couldn't as easily do another castle with it. That's why there's two different castle. I could make a third one if I wanted and as long as I stay within the limits of one room, It would work. Not with your version of the game. For the screen data, there's 16bits for every characters on the screen. There's bits in there for the AI of each monsters (some can walk only on bricks, some can climb on elevators, some can fall, some don't). There's bits to know what kills enemies, what kills player and in what way (water kills you except if you have air, phenom flowers kill you but if their in seed form, you can still pass over them if you hold the jump button, candles kill you only if you fall on top). These bits also keep track of which characters is a moving floor, a moveable obect, an enemy. Which characters is passable by the player or by an enemy (characters passable by the player aren't necessarly passable by the enemies). There's the direction of conveyor belts, which characters are doors. And when the character is an enemy, there's an index to the enemies table. Try putting this table in VRAM and see your Colecovision crawling at 1fps because you constantly have to retrieve bytes from VRAM each frames to determine all the characters actions. From automatic movements (conveoyor belts, falls, deaths) to voluntary movements (player joystick, enemies AI) to actions within the room (elevator changing direction, collectibles being grabbed, pushing blocks, etc.) Then there's the table where it keeps all the characters defined on screen in a table, for each 3rd of the screen. Yes, you can have a white brick at char #128 on the top screen, at char #00 in middle screen, and at char #60 on the bottom screen. This is done because you can never define all the possible graphics in the game at once. The characters are alloted as needed when the room is first drawn on the screen. Keep in mind that all enemies are done in characters, not sprites so there's no flickering. An enemy that can go in all directions needs 40 characters alone for its two animation frames + 2 facing sides (4 chars on a tile, 6 for in between, they move 4pxls each frame). As I said, you are welcome to try... if you don't, please stop with your "I'm a better programmer than you are" attitude. This is getting old.

Yes, It's preserved. In the original game you toggle 2 different speeds at the press of the 2nd button. In my version, there's 3 speeds. I added an intermediate speed. It wasn't hard to do and the intermediate speed helps a lot. It's fast but not too fast. The fastest speed is almost uncontrollable! It's best used while waiting to get on an elevator, or for it to bring you up to the upper room. Otherwise, it's very hard to play, hence the added intermediate speed. You access each speed with the keypads 1, 2 and 3.

It's not possible. I invite you to try instead of just talking out of... well... 722 bytes are used just to keep track of all objects state in the game. In the starting room, you kill one enemy, you grab one collectible, You open 2 of the 3 doors. If you return to that room later, the same enemy that was killed is still dead. The others are still alive. The collectibles you grabbed don't come back, the others are still in the room. The doors you didn't open are still closed, the ones you unlocked are still opened. Plus on the map the room will stay highlighted if you exit it. Visited rooms stay visited. There's 100 rooms in the game, each can have 16 doors, 16 collectibles, 16 moving blocks, 8 enemies. Do the math: 100*16+100*16+100*16+100*8+100 bits to keep track of all this, divided by 8 to find bytes. 3/4 of the available Colecovision RAM just went into remembering the state of everything in the game. I haven't even begun talking about why I need 1198 bytes just for the current screen interpretation (174 bytes more than the available RAM in Colecovision alone). Just with that, I don't get why you can't see how it isn't possible to do THE EXACT same game with all its features. If you take away a lot of features of the game, you probably could fit it in 1k RAM. But I didn't want to remove anything. All graphics, all sounds, all features, everything is there from the original game. It's even better with my code optimization. The game runs at 30fps even when there's 8 enemies on the screen (the original game slowed down considerably). And to answer your question: I liked this game. I wanted to do it on the Colecovision. It's as simple as that, why reinvent the wheel? Like you, I thought at first that I could optimize it enough to bring it back into the 1k RAM, but no. When I was already far into the game, I saw that it couldn't be done without severly cutting into the game. Even if you build it up from scratch, you will HAVE to cut into something. So I continued with the idea that it could at least run on an Adam computer. Then there's the SGM option that I added because Toby asked me. I don't even have one to test it out. Toby did all the tests on the SGM.

Read what I wrote in my earlier post. No, it's impossible to do this exact game in 1k RAM. You will have to sacrifice something to get it to run in 1k. Be it a lot of graphics/colors/anti-flickering methods. And believe me, I tried every which way!

OK, I'm here to "righting" some wrong information in here. First, I ported the game from the SG-1000 version of "The Castle". That cart has 8k RAM on board. I repeat what I wrote before: It is impossible to do this game in 1K RAM. Sometimes on the Colecovision you can get away by using some of the 16k VRAM as extra RAM, but in this game it wasn't feasible. There's 722 bytes just to keep the states of every opened doors/visited rooms/killed enemies/objects destroyed. There's 1198 bytes used to store the current screen in manageable form for the program (what is solid, what is deadly, what is an enemy, movable object, door, etc.). Then, there's a 290 bytes table for each objects to remember which character they use on the current screen. There's so much different graphics that you can't define everything in VRAM and call it a day. Every room must allocate characters dynamically to each objects drawn on screen. It keeps track of which characters go to which objects in these tables. Then, the game can support up to 8 enemies on the screen at once, 16 moving floors, 16 objects, 16 collectibles, 16 doors. The game must keep track of all this since it's possible to have all those things in a room at once. You need 299 bytes to do this. See now how it isn't possible to run this game in 1k, at least, without sacrificing a lot? I could have remove all the different type of bricks, so no colored bricks, no slanted ones, etc. I could have remove the different types of blocks, they all behave the same (except for the candle). I could have change all the enemies to sprites to conserve characters. But you would have been in flickering and single colored objects hell! Everyone of those options would have made the game uglier and not as interesting. And for those of you that think this is a straight port. I have reprogrammed almost everything. See how the original game slows down considerably with multiple enemies on the screen. Mine doesn't. I always do this with my ports. I reprogram everything I can to optimize the code for the Colecovision. Finally, the game DOESN'T run on Colecovision without an SGM. It runs on the ADAM computer WITHOUT an SGM though.

The Castle and Castle Excellent had 8k RAM in the original cart. I tried to optimize this so only 1k could be used but it was impossible. The thing is, there's so much graphic characters in the game that it's impossible to define them all in one go. Each room build its own set of characters dynamically as needed. So there's some huge table in RAM to keep track of what character is what. Also, the game remembers all the rooms visited, all the objects collected, all the enemies defeated, all the doors opened. With 100 rooms total, a handful of enemies+objects+doors per rooms, that's a lot of bits needed in RAM to remember their states! The game can be played on the Colecovision console + SGM as well as on the Adam computer WITHOUT the SGM. So that's always a possibility for those of you that doesn't have the SGM (like me!)

The castle layouts are completely different. That's the extent of the differences. Well, there's also different graphics on the title screen and hud. It's like the Lolo games on the NES: All different layouts with the same game engine. I'd say Castle Excellent is harder to figure out than The Castle, which is logical since The Castle came out first. The Castle is the best to start with since it introduces the various game elements at a more manageable pace.

Or rather, it's Space Taxi that's a little premature... I haven't written a single line of code yet for the game!

You're welcome! Archon should be fairly simple to do on the Colecovision, If I remember correctly, the pieces on the board are all monochrome so they could all be rendered without that sprite flickering that plagues a couple of CV games. There is no scrolling, the collision detection subroutine should be pretty simple, the game is small enough to fit on a cart and it doesn't probably use a lot of RAM. So yes, probably a pretty easy game to do on the CV. But, as I said in my previous post, not a single line of code can be lifted from the original game, everything would have to be recoded. Well I guess it still is faster to do an oldie than a new game. You don't have to spend time on creating the game itself, the rules, the animations, the musics are already done. It's just a matter of rewriting the game well enough on the new console. Yeah, Wizard Siege... my Duke Nukem Forever... (in developement since 2001 I think!) Well, the core game is pretty much finished. The game is 100% playable. What's missing is adjusting the parameters like the speed of the ball, the time it takes to accelerate, the wizard apparitions frequence, etc. I'd like to add sounds and musics. And a couple of levels (I have about 20 levels done IIRC). What I want to do is complete the game to my satisfaction, then fill the rest of the cart with as many levels as I can squeeze in.

Porting a game from the C64 amounts to basically reprogramming the game entirely. It's feasible, but it's as long as programming a new game entirely. That may be the reason why we haven't seen a lot of those yet. The only thing you can really port realisticly from a C64 is the rules of the game or some internal calculations (like the AI). Even then, you have to reprogram it for the Z80 processor. Also, lots of things on the C64 are fairly difficult to emulate on the Colecovision and, depending on what it is, it can even be impossible to do properly. The most obvious one is hardware scrolling. It can be done on the CV but lots of graphical details will be lost in the translation. There's also the hardware collision detection between sprites or sprites/background, which, for example, Space Taxi uses exclusively. 64k RAM vs 1k RAM, and the 32k "normal" cart limit are hurdles that can't be overcome in a lot of games (except by using special cart or the super module I guess). By the way, I'm the one doing the Space Taxi Coleco game. I disassemble the original game just to get the original movement calculations routine, since this is one of the most important part to get the original game's feel. This is the only salvagable code from the original game though. The rest will be all redone. Also, if the game is released on a normal 32k cart with all 24 levels, I expect some things will have to be stripped down. Don't worry though, the talking passengers will stay in! I'll use the same routine as in the Squish'em Sam game, which Daniel Bienvenu worked his magic on it to make it even better (I think it was back in 2003...)! Also, I thought about doing the Trolls & Tribulations game a while ago. The only real problem with this game is the hardware scrolling. But as the game has a mostly monotone feel in its presentation (mostly gray and blue), I think it's possible to make it look good on the Colecovision even with smooth scrolling.

Hi, When you are directly above the area where the 2 gold nuggets are, you have to dig 2 contiguous holes on the platform you are standing on, fall in, then dig another hole on the second platform. As you progress through the game, you'll see a lot of those enclosed areas, with varying amount of platforms above. Essentially, you must dig as many holes on the 1st platform as there are platforms to go through. Then on each subsequent platforms, you dig all the holes you can (which will always be one less hole than the previous platform) I tried to keep the game as close to the C64 version as possible. That's why I didn't put in extra music. I did program a couple of different jingles that play when you finish a level though.

Like everyone said, it's hard to pick just 3! But here are my picks 1 - Jumpman Junior (probably my favorite game of all time, along with its older brother Jumpman) 2 - Miner 2049er (what can I say, I love platformers!) 3 - Frenzy (I'm still playing this game fairly often) Honorable mentions go to Spy Hunter and Lady Bug (I told you, I couldn't just pick 3!)

Je suis vraiment désolé également d'apprendre cette triste nouvelle Daniel. Mes pensées sont également avec toi.

Just sent my serial numbers. One for my CV bought in 1983 and for my Adam Computer.

I kind of agree with you on this. I much prefer slight improvements (to get rid of slightly annoying things like the title delay or limited video outputs) than a more powerful version of my beloved Colecovision console. Call it nostalgia or insanity, but I love having all those limitations when I program the thing! If I want to program for a more powerful console, there's a lot of other choices available!

I'd much prefer a real button for the pause function. I hate everything that doesn't have a tactile response, I either accidentally pass over the sensor (happened too often with my original ps3), or I can't tell if it detected me properly.

There's no way to turn the music off. But the music only plays for a couple of seconds each time you grab the last gold ingot in a level. It's used more like a sound effect than anything else, just like the C64 version of the game. You're more likely to wake the whole family when you inadvertly stub your toe on the coffee table in the dark!!

For the BIOS hacking, you need to be careful to not move anything else out of their original address range. Lots of games, for example, reference the char patterns for letters/numbers directly. Even Coleco made games are guilty of that (though they usually use the pointers near the start of the BIOS code). Some also use subroutines that weren't mapped in the "jump table", like the ones for flipping and rotating patterns.

I'm very interested in this! Count me in! The most interesting feature for me is the component/composite video output. Removing the BIOS artificial delay is also a great idea.

Duly noted! I'm not writing comments in my code anymore! Must be more specific!!

Yep! Press left to dig left, press right to dig right. It's probably the one thing that kept me from fully enjoying the C64 version. Coutless times I died because I couldn't position myself properly for a dig. It was especially aggravating when you had to dig a couple adjacent holes: dig first hole, go back then push forward just a bit, dig another hole and repeat. Many times I would overshoot the "push forward a bit" and end up digging the same hole I just dug before. Not anymore in my Colecovision version! You can easily run in a direction while digging holes in the other.

Merci à toi Daniel de m'avoir permis de réaliser un de mes rêves, de programmer un jeu sur ma console favorite. Grâce à toi, j'ai découvert l'univers du "Colecovision homebrew". Quand j'ai vu pour la première fois ton superbe jeu Dac-Man, ça m'a donné le goût d'essayer moi-même. Grâce à ton aide précieuse j'ai pu réaliser mes 2 premières versions de Penguin Land et Lode Runner. Je t'en suis éternellement reconnaissant!

Hey everyone, I just sent the final version of the game to JF today. I spent the last 5 days testing all the features and levels to be sure everything is in working order. If you're still interested, here's what I've added to the game since last time: Speed selector. You can choose between fast (default) or slow speed on the title screen or anytime during the game with the "#" key. I put "Fast" as the default speed because it's really the best way to play. It's more exciting and satisfying. Even if you think you're not good enough, once you go fast, I'm pretty sure you'll never return to slow again! Anyway, the choice is there throughout the game. Different colored floors. Each 10 levels completed will change the colors of the floors and status bar. This will keep things interesting. A demo after the title screen. "Continue" option at game over screen. You can always resume the game at the last level you reached after losing all your lives. Your score is reset though. With this and the "level select" cheat, you can play any of the 150 levels at anytime. Enemy walks slower now. Not by much! But I made it so the timing is exactly like the C64 version. In that one, the more enemies on screen at a time, the slower they walk. With 2 enemies, they walk half of your speed. With 5 enemies, they walk 2/5 of your speed. The rest is in between. Screen savers everywhere! Well, everywhere the game is waiting for a user input (pause menu, level select cheat, etc.). Screen saver itself is nothing fancy, just a blank screen. Just trying to save those old CRTs!!! There's 8 melodies that play (chosen at random) when you grab the last gold. If you're a fan of metal music, you may recognize some riffs in there! Also they can play on 3 different musical scales to keep things interesting. Stats on game over. The game over screen now display the final score, the last level played and the amount of levels passed. That last one is interesting when you complete the 150th level because the game continues with the levels chosen at random. Also interesting if you use a certain "random levels" cheat... You can cheat freely (bypass a level, add lives, level select, etc.). The only difference is that the score changes colors to indicate that it has been obtained through a none conventional method. So, as you can tell, I've been really busy those last months. I hope you'll enjoy the game!