Calimari Carl (unfinished SSGC game)

[Opry99er]

Thanks retroclouds!! Yea, Karsten's title screen graphics are quite awesome. . The game is still pretty weak and only about 50% done, but with that title screen--- who cares?? We're a lucky community to have such talent. Karsten's graphics, SPECTRA, Tursi's emulation support, Jon's boards--- Pitfall, Tutankham, matthew's tutorials.... It's so cool

to be here in these times. Did you try the code out Filip?

[Opry99er]

**Code updated. Now, the diver and enemies do not reset to default position, but keep going after you collect a tank. You get an extra 10 oxygen when you collect a tank. Starting to be a bit more fluid now. =) I hope to keep this progress going. Next: treasure chests! =)

 

*** Try this new code and let me know how it feels. =)

[Opry99er]

Click the following link if you would like a copy of this demo in DSK image format.

 

http://www.opry99er.com/resources/CARL.zip

[Opry99er]

In thinking about this straight conversion to assembly, I want to keep the game premise simple and keep the code pretty simple and easy to read. I might change much of this code to single statement lines with a bunch of comments before I start the conversion.

[+retroclouds]

Thanks retroclouds!! Yea, Karsten's title screen graphics are quite awesome. . The game is still pretty weak and only about 50% done, but with that title screen--- who cares?? We're a lucky community to have such talent. Karsten's graphics, SPECTRA, Tursi's emulation support, Jon's boards--- Pitfall, Tutankham, matthew's tutorials.... It's so cool

to be here in these times. Did you try the code out Filip?

 

Yes, I did try it with classic99 yesterday evening at home. Very nice

[sometimes99er]

In thinking about this straight conversion to assembly, I want to keep the game premise simple and keep the code pretty simple and easy to read. I might change much of this code to single statement lines with a bunch of comments before I start the conversion.

Good idea.

 

Here's another idea. Throttle your emulation. Break it down a bit, simplify, logical sections, more lines doesn't matter, consider moving the sprites yourself (no automation), add speed controls overall and/or on objects, and consider integrating collision detection as you move each sprite (no coinc). This should hopefully help you once you start "translating".

 

A line-by-line conversion is a good idea. Keep the Basic statements in the comments of the assembler source (as Tursi did). It will make it easier for yourself and others.

 

I've played the game too. There are still some diver and tank collisions being missed - like I have to travel to the edge and back before it hits.

 

Edited September 9, 2010 by sometimes99er

[Opry99er]

Yes, and I cannot figure out why it does that..... The collision thing. All I'm doing is coming up with a random integer that is within the screen parameters for the X and the Y.... Then I am checking for a collision between my PC SPRITE and that location by multiplying the integer by 8--- per each 8 pixel screen tile. Theoretically, it should work, and DOES work 85-90% of the time.. But there are those instances where you are forced to "find" the pixel (with tolerance) and it's driving me MAD.

 

I thought that setting boundaries for the tanks and keeping them on-screen would fix that, and it DID help, but it's not fully operational just yet. I might try playing with the tolerance and see if I can tighten it up a bit. Also need to set the boundaries for the diver--- can't have him going offscreen.

Edited September 9, 2010 by Opry99er

[Opry99er]

I have cut up the code into single statement lines with REM statements for each section of code... I'm not sure how closely this will mirror the routines that will be implemented in assembly, but at least it makes the whole thing alot more understandable. =) Please check out the new code and give it a rip. I haven't even tried it out yet, as I'm on my Mac right now doing all this in a text editor, so I don't have emulation available. If it works like I expect, there will be no performance degradation, and it should run as it's always run. Thanks for keeping up with progress... this newly formatted code should be pretty simple to look at and understand... It's pretty cool to see it all cut up and compartmentalized... =) Reminds me of writing BASIC programs back before I had an XB cart and no emulator. =)

[Opry99er]

Code has been broken down even further into very small chunks, mostly 2-3 instructions per REM statement. I am beginning to see how simple this could really be in assembly. =) Register usage makes so much sense... I just need to get this darn XB game done so I can start having fun. =)

 

Again, I haven't tested this new code--- the broken down code. I have kept a version in multiple-statement lines and without most of the REMs... but I'm pretty sure this new code works. No reason for it not to. =)

[+adamantyr]

Code has been broken down even further into very small chunks, mostly 2-3 instructions per REM statement. I am beginning to see how simple this could really be in assembly. =) Register usage makes so much sense... I just need to get this darn XB game done so I can start having fun. =)

 

Again, I haven't tested this new code--- the broken down code. I have kept a version in multiple-statement lines and without most of the REMs... but I'm pretty sure this new code works. No reason for it not to. =)

 

Yeah, implementing an XB program in assembly is a great way to learn how to do it.

 

I did it myself with TI-Trek. That one was tricky because I decided to re-utilize the mathematical functions... which meant using XMLLNK and GPLLNK. Not so bad for tagged code, but a pain in the butt to implement with memory images.

 

You can see my source code and download the disk here: http://www.adamantyr.com/misc/titrek.html

 

Adamantyr

[Opry99er]

Thanks for that source code!! Certainly something I can learn from. =)

[Opry99er]

Hey adamantyr, question for you. How "complex" a game was TI-TREK? This current game I'm working on is pretty simple--- I imagine once the font is in and the treasure chests--- the multiple levels, etc., I imagine the game will be twice this size. However since level changes won't be much more than a difference in water height, water color, enemy graphics, and speed, they won't add much complexity. Arcade games are easier to design than other types of games, I've learned....

[Opry99er]

<<post deleted>>

Edited September 9, 2010 by Opry99er

[+adamantyr]

Hey adamantyr, question for you. How "complex" a game was TI-TREK? This current game I'm working on is pretty simple--- I imagine once the font is in and the treasure chests--- the multiple levels, etc., I imagine the game will be twice this size. However since level changes won't be much more than a difference in water height, water color, enemy graphics, and speed, they won't add much complexity. Arcade games are easier to design than other types of games, I've learned....

 

TI-Trek was a great example of very bad BASIC programming, actually.

 

A great deal of the program was haphazardly organized. Maybe the original writer had some grand overarching scheme to his placement of code, but if it was there, I couldn't see it. I just saw a lot of spaghetti logic and GOTO's where there was no real call for it.

 

Converting the graphics was easy... practically a copy and paste job. The sounds were a little more difficult to replicate, because some of them were using loops and decimal mathematics to determine the sound to play. Assembly language is better with iterative sound lists, so I ended up "faking" it a bit.

 

The parser for entering commands and directions was probably the most complicated bit of code, as most parsers are. That's one reason I decided not to use any parsers at all in my CRPG; way too much error-checking. Utilizing the mathematical functions wasn't too bad, the process is fairly clear in the E/A manual. These days, I'd have found a way to use integers instead, because mathematical accuracy isn't necessary for the scope of the game.

 

Adamantyr

[Opry99er]

Well, just knowing that someone writes crazier code than I do makes me feel better! Sometimes I look at my XB code and can't believe it works!!

 

I'm trying to keep the code for this game very clear and easy to understand--- you can be the judge of that. . The most updated code is at the top of this thread--- I think it's pretty easy to understand. Anyway, thanks for the reply--- I'll DL TI-TREK, the original and your EA version and see what I can see. Thanks!

[Opry99er]

Do I need to address these tables directly by the memory locations or can they be symbolically addressed?

 

SPRITE attribute list begins at >0300

SPRITE descriptor table -->0400

Character def table >0900 to >0AFF

[+adamantyr]

Do I need to address these tables directly by the memory locations or can they be symbolically addressed?

 

SPRITE attribute list begins at >0300

SPRITE descriptor table -->0400

Character def table >0900 to >0AFF

 

Either will do. Keep in mind these tables are relocatable by manipulating the VDP registers, so hardcoding them isn't probably a good idea.

 

I usually use EQUate labels for most of my VDP references, so I can keep them all in one place but have the compiler replace them with literals later.

 

Adamantyr

[Opry99er]

Gotcha. Thanks alot... I'm setting up a template for my game conversion(s) and I'm just wanting to make it as efficient as possible. I need to familiarize myself with how cart ROM works.... Reading the SPECTRA docs as we speak... Hope to find my answers there.

[sometimes99er]

Code notes

 

1) There are a few spaces missing in line 180 and 190.

 

2) TI XB won't accept lines beginning with and ***

 

 

Aquatic plants above are taken from ZX Spectrum version of Barbarian by Psygnosis.

 

[Opry99er]

That's very cool man! On the code notes--- yea, I know XB doesn't like those characters--- they are in my text file where I do alot of coding, and I use that stuff (plus the non-lined REM statements) just to separate my code out. If you copy and paste into Classic99, it just gives syntax errors on those lines and leaves them out of the final listing--- which is the plan...

 

I need to change my screen up... Add an ocean floor and move my statistics somewhere--- I'd like to lower the waves (as you suggested before) and tighten up the playing field some more.

 

Thanks for not forgetting old carl.... He's an old fella.

[sometimes99er]

As reference for the plants: An image from the original Barbarian from Atari ST, and one from the ZX Spectrum (Timex Sinclair 2068).

 

[Opry99er]

Wow--- that looks great.

[Opry99er]

I'll post completed code in the next few days. I'm trying to eliminate the automotion and make screen draws faster. Anyway, just about done. Sorry for being absent the last month... Been on the road busy busy busy

[sometimes99er]

Not seeing one bloody comment from you in about a month did worry me. Did you read the forum anyway (as a guest) ?

 

[Willsy]

Code notes

 

1) There are a few spaces missing in line 180 and 190.

 

2) TI XB won't accept lines beginning with and ***

 

 

Aquatic plants above are taken from ZX Spectrum version of Barbarian by Psygnosis.

 

 

Have a look at Scuba Dive for the ZX Spectrum... VERY doable on the TI I think...

 

http://www.youtube.com/watch?v=JW8nX7x9ML0

 

Beautiful graphics