Jump to content
retroillucid

Castle Boxset - Limited Edition / Pre-order

Recommended Posts

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.

Edited by tabachanker2
  • Like 3

Share this post


Link to post
Share on other sites

 

You speak alot about code theft, but you don't mention graphics theft or game clone

There's no differences between all those

 

But I'm kind of your side though, I highly prefer having original games over ports

 

Agree with you.

 

The difference is that code is copyrighted . Game concept no.

 

Graphics if you do your own are not copyrighted even if you get inspiration of something existing.

 

You can even do a copy of a "Picasso" if you don't sign "picasso" or sell it as a "picasso" there is no issue.

 

We did an error calling the blue dwarf game "Smurf" , but if we would have called something else we won't have any issue with the right holder.

 

My games are all inspired from others existing games but enough different and none of bytes of code have been stolen.

 

Even now, (that was not the case before) , the musics are orignal ones , composed specially for the game. My new publisher is very sensible about legal issues.

Edited by youki

Share this post


Link to post
Share on other sites

 

 

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.

 

 

 

Thanks for the precision.

 

But , if you reprogram almost everything , what you don't start from zero ? You will have more possibilities to optimize the game as you wish . And i'm sure rewriting the game from zero you will have managed to make it run on stock colecovision. (with may be the help of a megacart)

Share this post


Link to post
Share on other sites

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!

Edited by tabachanker2

Share this post


Link to post
Share on other sites

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!

 

I'm pretty sure it is possible. I don't say it is possible starting from the existing code, i say it is possible starting the game from white sheet. and i don't say it easy ,but doable.

 

But never mind , you did not answer to my question that was : "if you re-program almost all the game when you do a port , why don't you start from zero? "

 

 

BTW , The castle is an excellent game!. But it could have been even better with graphism reworked by Retroillucid! :)

Share this post


Link to post
Share on other sites

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.

Edited by tabachanker2

Share this post


Link to post
Share on other sites

Quick question for you, Steve: If I remember correctly, the SG-1000 version had a speed throttle feature which could be set via one of the fire buttons. So the player could slow down or accelerate the gameplay to his liking. Was this feature preserved in your port?

Share this post


Link to post
Share on other sites

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.

Edited by tabachanker2
  • Like 1

Share this post


Link to post
Share on other sites

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).

 

 

 

Just an example. You say each room can have 16 doors. Ok... but when i look the game i see no room with 16 doors, the maximum i have seen, i think is 5.

For the moving block , the state is not keepped when you exit a room and then go back , moving block are at initial state.

 

So redo the math : ( ( 5 (doors) + 0 (moving block) + 16 (objects) + 8 (enemies) ) * 100 ) / 8 = 362 Bytes , where you have : 700 Bytes.

 

And even you need the moving block state , you will be at 562 bytes.

 

For your screen interpretation, i don't know what you do inside , but there is may be other approachs.

 

There are so much different way to do things.

 

You have also at least 2K of VRAM free , i think. You could may be even save 4k more by using the not official Screen 2 mode_text . (or even 8K , if the game does not use more than 8 sprites). As all type of object are not in each room , you have surely a way to optimize number of different graphics patterns.

 

etc..etc...

Share this post


Link to post
Share on other sites

 

Just an example. You say each room can have 16 doors. Ok... but when i look the game i see no room with 16 doors, the maximum i have seen, i think is 5.

For the moving block , the state is not keepped when you exit a room and then go back , moving block are at initial state.

 

So redo the math : ( ( 5 (doors) + 0 (moving block) + 16 (objects) + 8 (enemies) ) * 100 ) / 8 = 362 Bytes , where you have : 700 Bytes.

 

And even you need the moving block state , you will be at 562 bytes.

 

For your screen interpretation, i don't know what you do inside , but there is may be other approachs.

 

There are so much different way to do things.

 

You have also at least 2K of VRAM free , i think. You could may be even save 4k more by using the not official Screen 2 mode_text . (or even 8K , if the game does not use more than 8 sprites). As all type of object are not in each room , you have surely a way to optimize number of different graphics patterns.

 

etc..etc...

As you know, I am usually of the same mind set as you re. a lot of things around here, but

 

LET THIS ONE GO ALREADY!

 

Please. :waving:

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

 

 

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.

 

I have never said or even think i'm a better programmer than you. I was just discussing technical point of view. You said "it is impossible" , i say "i think it is possible having a totally different approach". And reading your posts , btw very detailed and very very interresting , i'm more and more convinced it could be possible.

 

No, i won't try , or said, i won't try to reproduce the exact same game as you already did it. But may be one day , i will do something with the same level of complexity , may be a kind of sequel . a Castle like game has alway been a game i wanted to do for colecovision.

 

But as the discussion annoys you , i stop. Thanks to have sharing this technical details.

Share this post


Link to post
Share on other sites

As you know, I am usually of the same mind set as you re. a lot of things around here, but

 

LET THIS ONE GO ALREADY!

 

Please. :waving:

 

It was really just a technical discussion here.

  • Like 1

Share this post


Link to post
Share on other sites

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 :

 


Having MSX game and SG1000 game on Colecovision is good for whom not having access to these games. But making a business based on these portage is .... everybody knows what i think...

 

In addition most of games coded from scratch for the colecovision are better than all these port. Look at Sydney Hunter, Mecha 8 / 9 , Princess Quest, Risky Risk, Bomb jack ...and lot of other... and they do not require SGM.

 

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".

Share this post


Link to post
Share on other sites

If SG1000 had to add RAM to cart, then it would be very difficult to get this game running just using 1KB. The 2 of these games are pretty huge and quite complex. It's 1 huge level/maze/puzzle and takes about maybe 3-10 hours to complete. And writing and coding the game from scratch would take a ton of time. I played a bit of Castle Quest on the NES and just drown myself in Castle Excellent in BlueMSX few minutes ago.

I believe cartridge can have additional RAM, but it would have to be in the upper $8000 range. The game is 32KB, and there's no room for additional RAM to be added to the memory map, unless you make a bankswitching mapper. I think MSX and SG1000 have 48KB mapped to cartridge. So having SGM or an ADAM computer is a good compromise.

Share this post


Link to post
Share on other sites

I don't discredit your port, i'm against the ones who make business with...

 

I have nothing against porting ( by porting i mean Hacking) a game , but making profit of it , yes.

 

And yes, i assume what i say , most of games coded from scratch nowadays are better than most of msx port (released commercially in the 80's). Just because, now, coder have better tools and not time/business constraint.

 

And i'm sure if YOU would have started from scratch you could have make it even better that the game was originally. But i have understood it was not your intention from start ,you wanted to do the EXACT same game. I respect your choice.

 

Concerning the SG1000 , i was just not aware there was 4k RAM in the SG1000 cartrige, it is why i have believed you ported the MSX version.

 

And please point me , where i have say something like " I could do better than you" . My point from the begining is " starting from a white sheet, i think you could have make it run on Stock colecovision". And i still think that.

 

You say "it is IMPOSSIBLE" , so because you say , it is? Don't you find it a little presumptuous?

Personnally, I have seen lot of thing that lot of people think "impossible" done , what is impossible one way , could be possible using other ways....

 

Anyway , let 's stop here, it seems you are as sturbborn as me :) . So let say , we agree on the fact we disagree.

Edited by youki

Share this post


Link to post
Share on other sites

I don't discredit your port, i'm against the ones who make business with...

 

I have nothing against porting ( by porting i mean Hacking) a game , but making profit of it , yes.

 

 

Wait till you see my new Ferrari :roll:

 

Yes, I'm aware of what you and few other think (I've been aware of what you guys were saying on your french forum)

But hey, you're free to think whatever you want, but still, you don't have any facts, just pretending to know what exactly it is without even asking any of us

 

This ain't too different than Risky Rick you know.....

And honestly..... I like what the programmer did

But I couldn't care less if he have the authorization to make it or not

The game is freakin 30+ years old!

 

A N Y W A Y.................

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

 

Wait till you see my new Ferrari :roll:

 

Yes, I'm aware of what you and few other think (I've been aware of what you guys were saying on your french forum)

But hey, you're free to think whatever you want, but still, you don't have any facts, just pretending to know what exactly it is without even asking any of us

 

This ain't too different than Risky Rick you know.....

And honestly..... I like what the programmer did

But I couldn't care less if he have the authorization to make it or not

The game is freakin 30+ years old!

A N Y W A Y.................

 

To be honest with you , i don't agree 100% with that they have done with Risky Risk. i'm just very impressed by the technical aspect but i don't like the fact they did exactly the same game.

 

Speaking of the french forums , we are French, we have to "complain" (Raler in french) and give lessons , it is in our genes. :)

Share this post


Link to post
Share on other sites

 

To be honest with you , i don't agree 100% with that they have done with Risky Risk. i'm just very impressed by the technical aspect but i don't like the fact they did exactly the same game.

 

Speaking of the french forums , we are French, we have to "complain" (Raler in french) and give lessons , it is in our genes. :)

 

I can understand that

As you may noticed, I'm mostly only working on original creations nowadays, and I prefer that

I'm also not 100% agree on doing ports, as long as we are not releasing too much of them

 

I know how you guys are in France, I'm used to it now :P

But saying that we're doing it for the money or profits is total non-sense

Producing these boxset is more expansive than you might think

Share this post


Link to post
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.

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...