"The dude" - new WIP beatemup game developed in cc65

[Yaron Nir]

Emkay, looks cool

 

Source? Xex?

[emkay]

Check it out.

no_names.xex

[Yaron Nir]

And source?

Interested to see your dli. Is it all asm or also c?

[emkay]

Graph 2 Font

no_names.zip

[Yaron Nir]

I see. so basically you blit an image using g2f.

was more interested to see how this is incorporate inside an asm or c code.....

but it still looks cool

[emkay]

I see. so basically you blit an image using g2f.

was more interested to see how this is incorporate inside an asm or c code.....

but it still looks cool

It's really that simple to add those PMg to the background. IF your engine is working, you still could add that. Want to save memory ? Use the double lined PMg mode. Then it cost almost nothing: Low RAM needed and even better: rather low CPU is needed.

[emkay]

And a stretched PMg image , giving an other "depth" view.

 

 

 

Not to tell, if you use the graphics that way, you can benefit much more by the hardware features of ANTIC.

Also, GTIA can add some FX, by PMg register settings.

 

Just some "Pokes" here , just some "Pokes" there... and the screen is shaking.

[R0ger]

I did some debugging on Internation karate .. and there is nothing special in there really.

The sprites are stored unscrolled, unmirrored. Scrolling and mirroring is done with tables. It uses character mode, which means it doesn't have to process the empty areas in large sprites. Since the game uses only 1D scrolling, there is basically no code penalty over linear VRAM. Character processing code uses expanded loops of course.

Btw. maximum speed of the game is refresh per 3 frames. Which in my experience is quite enough to do a lot of processing, while still giving fluent experience.

Also game, which relies more on animations, rather than objects moving across the screen, will not benefit from higher refresh rate .. it would need unreasonable amount of animation phases.

[Heaven/TQA]

@Roger

 

What do you mean with 1D scrolling in IK?

[R0ger]

@Roger

 

What do you mean with 1D scrolling in IK?

 

The sprites .. they only move in X direction. The characters are broken into rows of characters. With 1D scrolling, you need extra character on each row to accommodate the extra pixels. But that's it. If it was 2D movement, it would be much more complicated.

[Heaven/TQA]

Yeah but that doesnt envoke scrolling it basicly moves the sprites?

[Wrathchild]

If I recall, the char graphics for the player animation frames are cleverly designed such that they resolve on 4 pixel boundaries and so the soft-sprite engine isn't required to shift anything.

Also I think the soft-sprite's char-maps are more efficiently stored as they only hold 'used' blocks, not 'empty' ones. (But that maybe C64 Barbarian as does something similar)

Edited May 13, 2019 by Wrathchild

[R0ger]

Yeah but that doesnt envoke scrolling it basicly moves the sprites?

 

By scrolling I mean shifting bits inside bytes.

[R0ger]

If I recall, the char graphics for the player animation frames are cleverly designed such that they resolve on 4 pixel boundaries and so the soft-sprite engine isn't required to shift anything.

Also I think the soft-sprite's char-maps are more efficiently stored as they only hold 'used' blocks, not 'empty' ones. (But that maybe C64 Barbarian as does something similar)

 

It looks like it, but it's not the case. If you try to make the shortest possible step, it will indeed move you 4 pixels most of the time. But not always .. if you will do it back and forth several times, you will end up on different positions inside byte. I didn't find code doing it, I just found the tables (since it's clear how they should look).

 

Other processing they must do is merging the front and back characters together.

PMG is used for coloring the second player. They use clever trick for that. The player doing attack last is in the front. So sometimes it's player one, and sometimes player two. So theoretically the PMG has to be sometimes masked by the player in front. But that's not how they do it. The PMG is used always for the player in the front, unmasked. Just the colors are swapped when needed.

Edited May 13, 2019 by R0ger

[Heaven/TQA]

so animations are preshifted in memory? and mirrored? don't think Archer did it on the fly?

[R0ger]

so animations are preshifted in memory? and mirrored? don't think Archer did it on the fly?

 

No, they are preshifted. It's done on the fly, using those tables. It seems shift and mirror is done first, and result is stored in extra buffer, one for each character.

Then these buffers are merged into final charset.

[Heaven/TQA]

Never thought of that slow approach.

[R0ger]

Never thought of that slow approach.

 

Indeed. But that's the thing. 1 frame refresh is standard since 2600 times. It's the only way to do it on 2600. But for most games, it's just pointless.

And once you aim for 3 frames refresh, soft sprites are no longer a problem.

 

And I think game like IK could be designed so you don't need shifting, the way Wratchild suggested. That would make everything so much easier. Which means you could either do it faster, or do much more stuff in the same time.

[Heaven/TQA]

And IK+ did the same? I mean thats 1 fighter additional.

 

But yeah me as demo coder its so obvious to think in 1 frame and LUT approach and preshift/precalc that sometimes such things are out of question.

 

And C64 uses sprites or same tech?

[Heaven/TQA]

But some how it makes sense...

 

1 frame render player 1, 1 frame player 2, 3rd frame buffer merge and copy to screen

[emkay]

Interesting how the thread has already left the road, but this time not badly.

The game is in no way similar to IK. Particular because it is more like Street Fighter: Small Sprites with fluent animations and freely moving. IK is far away from getting there. It's fun as it has been created.

And this is exactly one of those game styles that's missing on the Atari.

So please go back on Track and support the author.

[Yaron Nir]

I have no issue that my thread change the direction a bit

All conversations about sprites software sprites memory and shifting are most welcome here.

All good no worries

[emkay]

I have no issue that my thread change the direction a bit

All conversations about sprites software sprites memory and shifting are most welcome here.

All good no worries

See, no progress yet.

Meanwhile a question.

 

How many games exist for the Atari that uses the PMg for scrolling and using the color graphics for the "Sprites"?

The 2nd question: Why is that?

[José Pereira]

Why is you? Do you really exist? Of course you exist or we not have to take you...

 

P.s.- And that proposal from you for the beat'em'up game for the buildings using PMGs is so 2600 like, childish and has nothing to add to A8 games developments and coding.

Just said...

[emkay]

Why is you? Do you really exist? Of course you exist or we not have to take you...

 

P.s.- And that proposal from you for the beat'em'up game for the buildings using PMGs is so 2600 like, childish and has nothing to add to A8 games developments and coding.

Just said...

LOL a post from mr infantile.