Beyond Evil - now playable

[Heaven/TQA]

Greetings from the evil side... as more I get used to the chip set as more I realise how much quicker I get... no tricks here yet... no inline changes, no "DLIs" etc... just simple plain code...

c64g.zip

Edited May 3, 2008 by Heaven/TQA

[+Philsan]

Greetings from the evil side... as more I get used to the chip set as more I realise how much quicker I get... no tricks here yet... no inline changes, no "DLIs" etc... just simple plain code...

 

Do you know that with those 8 large multicolored sprites you're turning the knife inside of me?

[+Philsan]

DELETED

Edited May 3, 2008 by Philsan

[Heaven/TQA]

i know that it might hurt some people here but it hurts even more that i have to use 8x16x3 on c64 (ok.... not the scorpion here) instead of 12x21x3...

 

but both platforms can have an nice port of the game...so stay tuned...

 

maybe for some people here it might be interesting as well how a "multiplatform" development might look... so sorry for hurting...

[kenfused]

Greetings from the evil side... as more I get used to the chip set as more I realise how much quicker I get... no tricks here yet... no inline changes, no "DLIs" etc... just simple plain code...

So tempted to create a 7800 demo.

[Allas]

Fast progress, good!

 

I suspect The C64 version never could looks like the Atari version. It's true Atari cost a lot of giant effort, but the final results could be better. Looks at Bombjack for example.

 

Heaven. I have a little question for you. Yesterday I found a post from you about a method to recognized variables on Atari emulator. Basically, you have to compile your programs with:

 

MADS program.asm -t:labels.txt

 

And after that, you need to load on the Atari emulator the labels file with command LABEL labels.txt on monitor. But I get the error "Unknown file format". An example of my labels.txt file is:

 

mads 1.8.1

Label table:

00 003F SCR48

00 003E SCR40

00 003D SCR32

00 0014 CLOC

00 0000 BYT2

00 0100 BYT3

00 0080 FTMP

00 0082 REGA

00 0083 REGX

00 0084 REGY

00 D000 HPOSP0

00 D001 HPOSP1

00 D002 HPOSP2

00 D003 HPOSP3

00 D004 HPOSM0

00 D005 HPOSM1

00 D006 HPOSM2

.

.

.

 

I want to display memory contents of my labels and variables using names. It works?

[Heaven/TQA]

ken... sorry... Beyond needs 64k ram and i am not experienced enough with holy dma and vertical sprite movement through zones...

[Heaven/TQA]

Allas, regarding the labels, well... haven't used that for months so I am not 100% sure...

[kenfused]

ken... sorry... Beyond needs 64k ram and i am not experienced enough with holy dma and vertical sprite movement through zones...

I meant just of that commodore 64 screen. We could probably have more than 8 sprites running around on the screen without any on screen changes or interrupts.

 

It needs 64K of RAM beyond the ROM that would be needed for program code and static data tables?

[Heaven/TQA]

Ken, i thought about 7800 and 5200 but as it stands now...i need ram for generating the levels and holding track of all stats and items etc...

[Heaven/TQA]

hmmm... not sure if I should post progresses of the port here... but question...are you interested in seeing how multiplatform development of the game will look like?

 

or only interested (obviously) in the Atari version?

 

just let me know.

beyond_c64b.zip

[+Philsan]

You already know that I love Atari computers (1979) and I am not a fanboy so I am able to appreciate C64 (1982) and to stand the fact that perhaps the latter will have the best version (at least if you spend the same time programming on the two platforms).

 

My obvious answer is: yes, I am interested in seeing multiplatform development.

[Tezz]

hmmm... not sure if I should post progresses of the port here... but question...are you interested in seeing how multiplatform development of the game will look like?

 

or only interested (obviously) in the Atari version? just let me know.

Definately keep posting the progress of both here Heaven, it's interesting to see the development and evolution of your project

[Allas]

I didn't collaborate anything with this project ( oh this post have 10 pages ), but I think it would be a good idea to view the C64 progress on www.lemon64.com forum. And, of course, you can post the Atari progress here.

[Heaven/TQA]

Allas, for me the interesting part is to develope both versions in parallel. So I might get away from developing into one direction and then realising that it is nearly impossible to move to other platform (wether it is c64, c16, 7800, 5200, etc...)

 

and the good thing is as well... you get a feeling of what is the real bottle neck of which machine in terms of this type of game.

Edited May 5, 2008 by Heaven/TQA

[patjomki]

Allas, for me the interesting part is to develope both versions in parallel. So I might get away from developing into one direction and then realising that it is nearly impossible to move to other platform (wether it is c64, c16, 7800, 5200, etc...)

 

and the good thing is as well... you get a feeling of what is the real bottle neck of which machine in terms of this type of game.

 

Well, you shouldn't be too optimistic. My experience in developing games for both platforms is that you either get a great game for one of the target platforms and a disappointing game for the other OR you have a game that is average on both platforms.

 

My hopes are that you still try to develop your game for the ATARI as target platform.

 

Regards,

 

patjomki

[Rybags]

Nice use of gradients in the text there.

 

IIRC, the C-64 actually has 9 luminence levels.

[Heaven/TQA]

Patjomki, yes, you could be right and I appreciate your experiences.

 

So don't mind in sharing your thoughts in more detail.

 

I am tending to use bitmap mode for the game like f.e. Last Ninja. Why, because you can use more than "128" chars.

 

The Bomb Jack thread is interesting as well as Tezz and friends are developing a static screen plus softsprites engine incl. background. But as you see the price is high. a lot of work goes not into writing the actual sprite routines but in terms of available chars for gfx.

 

Tezz how many chars are available for sprites? 4 fonts are used for 1 screen?

[Tezz]

Tezz how many chars are available for sprites? 4 fonts are used for 1 screen?

Hi Heaven, yes 4 fonts are used on each screen, a maximum of 83 on the background graphics plus another 8 on the fixed ledge and bomb shape definitions leaving the remaining chars for the soft sprites which also have p/m overlays, Vega has been working hard the past weeks to optimise the sprite routines as we are hoping to add multiplexing for additional overlays. Edited May 6, 2008 by Tezz

[Heaven/TQA]

Hi Tezz, what about the ram usage for the preshifted data plus sprite routines? just to get a feeling of how many space i should take into count when using hardware sprites on c64 and soft sprites on Atari...

[patjomki]

Patjomki, yes, you could be right and I appreciate your experiences.

 

So don't mind in sharing your thoughts in more detail.

 

O.K. I am going to start with some general statements.

 

1) Sound

Writing sound for crossplatform games (ATARI/C64) is easier than graphics due to the fact that POKEY is able to do nearly everything that the SID can although it is not so well documented and you have to use the cpu to emulate filters etc. the SID has. So you have to choose whether you write an "SID emulator" like Swiety did (hopefully with less cpu usage) or try to rearrange the C64 sound with ATARI trackers.

 

I recommend arranging the sound on C64 due to more and better sound trackers. Apart from the fact that this results in faster development you still have a fourth voice left for ingame sounds on ATARI.

 

2) Graphics

This is the most difficult part. The C64 has higher color resolutions (standard mode 40x25 chars 2 colors) and highres-sprites (8 mono )sprites a 24x21 compared to ANTIC modes 20x25x5 colors and 5 mono players (4players+4missiles) 8x256 in lower resolution. With tricks like DLIs for pms you can results that are quite often similar to the C64 graphics but it takes more programming effort and the cpu is used more (which isn't a huge disadvantage because ATARIs cpu is faster)

 

On the other hand the ATARI (with ANTIC) is far easier to program regarding scrolling and then there is the advantage of overscan.

 

So from our point of view it was just a decision which game we wanted to code and then to choose whether to create the graphics on ATARI or C64. In either ways the result was that the source machine always looked brighter than the destination machine.

 

3) Game engine

Well, I don't have to tell you that due to the cpu similarities the game engine can be ported 1:1 most of the times (like you proved with Venus Express)

 

I am tending to use bitmap mode for the game like f.e. Last Ninja. Why, because you can use more than "128" chars.

 

Well. This will take to much memory.

 

The Bomb Jack thread is interesting as well as Tezz and friends are developing a static screen plus softsprites engine incl. background. But as you see the price is high. a lot of work goes not into writing the actual sprite routines but in terms of available chars for gfx.

 

I'd recommend this approach.

 

So keep my fingers crossed for your project. I am really looking forward to play it.

 

Regards,

 

patjomki

Edited May 7, 2008 by patjomki

[Tezz]

Hi Tezz, what about the ram usage for the preshifted data plus sprite routines? just to get a feeling of how many space i should take into count when using hardware sprites on c64 and soft sprites on Atari...

Well, as you know the ram usage is high for the pre-shift, it's the downside of this fast method. I was reluctant to use soft sprites for this reason but Vega doesn't like to use multiplexed hardware sprites with the inherant flicker, I've otherwise been impressed with the routines which are worked from TEBE's developments. The current BJ wip exe is over 200k, it's later planned for compression. It was hopfully to be released for 128k Atari's. Edited May 7, 2008 by Tezz

[Heaven/TQA]

Hello Tezz,

 

200kb unpacked, 128kb if possible which means 130xe... well...the sprite routines are impressive but if the price is min. spec 130 xe... my max. spec is 800xl... hmmm... well...

 

That is the thing regarding sprite, to make them fast and good looking you have to use a good portion of ram for unrolled code, preshifted data etc... not to mention the reduced complexity of background gfx. and things get more complex if you use pm overlays, too.

[Tezz]

That is the thing regarding sprite, to make them fast and good looking you have to use a good portion of ram for unrolled code, preshifted data etc... not to mention the reduced complexity of background gfx. and things get more complex if you use pm overlays, too.

Hi Heaven, Yes it is a bit of a bind with the Ram usage. Multiplexing the hardware sprites is that age old other option although it brings it's own complications but doesn't require the overhead of ram, plus there is the ability of more colours. The downside is mainly the flicker but as Crownland showed it's not so bad to use I think. The final Crownland used a more complex multiplex which allowed free movement, the preview used a more simple multiplex routine which didn't flicker. Either is acceptable to me. Most NES games for example used multiplexed sprites which certainly flickered. I would say that multiplexing using less ram and having the benefit of more colours but with some flicker outways the fast pre-shift software sprite routine with large ram usage and PF colours but I guess it's a matter of opinion. I think there's a medium between using some less taxing soft sprite routines and hardware sprites when designing (or recreating) a game from scratch, normally I find that another aproach would have been better but that's often the case in hindsight Edited May 7, 2008 by Tezz

[Oswald]

Hello Tezz,

 

200kb unpacked, 128kb if possible which means 130xe... well...the sprite routines are impressive but if the price is min. spec 130 xe... my max. spec is 800xl... hmmm... well...

 

That is the thing regarding sprite, to make them fast and good looking you have to use a good portion of ram for unrolled code, preshifted data etc... not to mention the reduced complexity of background gfx. and things get more complex if you use pm overlays, too.

 

 

if I were you, I'd use charmode as if it was a bitmap, ie each charset makes up 3 rows on the screen then changing to a new charset with a dli, totalling in 5 charsets for one screen.

 

benefits:

 

- you have 5 colors on a "bitmap" screen.

- you only need to scroll the char pointers, when scrolling (or maybe you can even do wrap-around with gtia? I dont know)

- you can use the extra 8 chars for char bullets, or items, etc.

- unlimited nr of softsprites.

- you can lay out the chars in columns, so you can index vertically through 3 chars (or 4 if you make your screen 32 wide, but forget char bullets then)

 

cons:

 

- more complicated to calculate screen adresses

- DLIs take away some time

 

I would also not bother to mess with pmgs for extra colors because they would limit the sprite routine badly, I'd use them for effects, bullets, etc. as for the preshifted sprites, I think you have no choice not to preshift if you want to have a busy screen maybe you can implement a preshift buffer with some kind of intelligent system which precalcs the shifts into it when a new 'unpreshifted' sprite enters the screen. xeo3 does this iirc. one very important thing would be to equalize the workload throughout the frames also...

 

also dont forget that in a game gameplay is often more important than nr of colors, or framerate

 

well so much blabbling for today