Jump to content
IGNORED

Uridium demo.


shoestring

Recommended Posts

Thanks,  that's a big relief. So essentially all that work has already been done previously. Although for the split screen, only 17 rows of shapes are plotted for the dreadnoughts,  there are 2 rows above and below reserved for the stars and the manta never moves beyond the boundaries of the dreadnought. So I'm not sure why the developer included those, I suppose because he could afford to do it. 

 

I recall only counting 280 unique tiles last night ( $7800 - $7FFF ), the rest are empty. There's also a character in that range reserved for the player bullets which are actual characters ( not sprites ) , the background character is copied to one of the reserved spaces then the bullet is combined before being copied to the screen. So for the soft sprites, this means they have to be overlayed whenever a bullet travels underneath them, and that's after the bullets have been overlaid a background character

 

I'm assuming popmillo's program doesn't run properly under Win10? You could try running it under VM

 

 

Link to comment
Share on other sites

20 hours ago, José Pereira said:

 

 

P.s.- Program to get is just number of chars per wanted number of Interleaved Charsets and is from @popmilo...

I'm with a problem using here Windows10 where previously was 7 so have to wait for his answer or I'll say you right now how many chars this level have for the 3charsets.

:thumbsup:

 

I believe it should be 2 character sets not 3. G2F seems to duplicate most of the characters on the first line and re-arrange some of the others.

 

Not sure if I am importing into G2F incorrectly. Charpad has the correct layout when I import the same .fnt file ( 256 characters ). So that's where the confusion lies.

 

CharPad

 

image.thumb.png.e27a650c97610b09ea4e5843e9e97897.png

 

G2F

 

image.thumb.png.e87db53cb62384416e44ef6efe20fbf7.png

 

 

I had to re-make level 04-Gold from scratch using the original character set as I have no way of keeping the same layout once I import an image, it automatically optimises the character set. I've attached the Charpad project here as well.

  

 

 

07 - Gold.ctm

Edited by shoestring
Link to comment
Share on other sites

me just had a quick look over that thread... but don't want to be a downer here... but have you really really thought how you would handle the sprites? before that... forget the background scrolling thing... I know I know... low hanging fruits and keeps you motivated. Don't get me wrong here...

 

but as Jose mentioned... if you decide to use softsprites like on Spectrum etc... I just see the way to go with interlave charsets... means on charline separate chars... which might give you enough chars free for the softsprites...

or you search the forum for the legendary Menace demo... where I learned how to do softsprites... by reserving dedicated chars for copy sprite data into it...

Uridium without its attacking waves is...well... no Uridium... and Mirax Force e.g. that's dumb simple sprites not crossing each other to avoid flickering or other mess.

 

 

Edited by Heaven/TQA
  • Thanks 1
Link to comment
Share on other sites

Not really - fine scrolling just means an offset calculation is needed, not much extra overhead.  Although greater DMA load = less rendering time.

I'm fairly sure the enemy count is limited to 5.  Though throw in mines and shots it means extra objects.

 

Though be warned - Atari has already once been embarrased by this game.  Poor ST conversion from in the day.

Apparently there's been recent work on an STE version that more closely matches the original but I don't know if anything has been released.

 

 

 

Edited by Rybags
  • Haha 1
Link to comment
Share on other sites

15 hours ago, shoestring said:

I'm assuming popmillo's program doesn't run properly under Win10? You could try running it under VM

Today with another version of him and with ours two talking from yesterday now there's the proof that is nothing related to Windows versions installed but is that I was and still am now on a public place so the computer(s) have some things blocked and most .exe(s) needs Administrator priviledge that, of course, I and all others users don't have. It just erase only the .exe program inside the folder after extracting all the files.

 

No problem, I already sent @popmilo this 1st level map and will post me and/or here the number of chars per charset.

 

 

Link to comment
Share on other sites

3 hours ago, shoestring said:

I believe it should be 2 character sets not 3. G2F seems to duplicate most of the characters on the first line and re-arrange some of the others.

Let me first have all the levels map and see how many chars they have each...

The reason for 3 Interleaved charsets is because of its use for soft sprites. 

I think we can have enemys in [3x3]chars including shifting = [9x17]pixels .

Will keep you update.

:thumbsup:

Link to comment
Share on other sites

3 hours ago, Rybags said:

Not really - fine scrolling just means an offset calculation is needed, not much extra overhead.  Although greater DMA load = less rendering time.

I'm fairly sure the enemy count is limited to 5.  Though throw in mines and shots it means extra objects.

 

Though be warned - Atari has already once been embarrased by this game.  Poor ST conversion from in the day.

Apparently there's been recent work on an STE version that more closely matches the original but I don't know if anything has been released.

 

 

 

Jeeeez.... that’s poor...

  • Like 2
Link to comment
Share on other sites

Just a hint:

If I'd do such a game, I would use the PMG for the platforms of the ship(s) . 

I'd not use the hardware scrolling, just some character set rotation. 

All moving objects on the screen would be created by characters, as enemy attack waves look low in details, and all enemies of an attack wave look the same. Imagine them using a rolling character cluster, simulating the scrolling...

 

The "walls" and some details in the background could be done using characters aswell. The moving PMg would cover a lot of clipping. And the game could run at one frame. 

Edited by emkay
Link to comment
Share on other sites

1 hour ago, emkay said:

Just a hint:

If I'd do such a game, I would use the PMG for the platforms of the ship(s) . 

I'd not use the hardware scrolling, just some character set rotation. 

All moving objects on the screen would be created by characters, as enemy attack waves look low in details, and all enemies of an attack wave look the same. Imagine them using a rolling character cluster, simulating the scrolling...

 

The "walls" and some details in the background could be done using characters aswell. The moving PMg would cover a lot of clipping. And the game could run at one frame. 

Interesting approach. I mean the idea of having the big ship as quadruple 4x expanded players... so rest is charset. Any game did that?

Edited by Heaven/TQA
Link to comment
Share on other sites

11 hours ago, Rybags said:

Though be warned - Atari has already once been embarrased by this game.  Poor ST conversion from in the day.

The ST doesn't have hardware scroll out of the box, so that's to be expected from shoddy coders but you can still do decent stuff like RTG

 

 

The scrolling area is only about 100 lines high but I think it could have been better (although it may just have been a memory issue as I think the game ran in 512KB)... and with hardware scroll discovered later, it could have been fullscreen.

 

Back to the topic, modeE and software sprites is the way to go obviously ?. As usual mode4 doesn't provide any speed benefit (probably the opposite), and no color benefit. Perhaps a bit of mem saving ?

 

Link to comment
Share on other sites

13 hours ago, José Pereira said:

Let me first have all the levels map and see how many chars they have each...

The reason for 3 Interleaved charsets is because of its use for soft sprites. 

I think we can have enemys in [3x3]chars including shifting = [9x17]pixels .

Will keep you update.

:thumbsup:

 

Ah of course, well for the enemies here is an example Sprite sheet. 

 

Enemies fly higher, so they don't need to cast a shadow, they also do not collide with the player.

 

image.png.06e0d172df9258d47a76c2f5949f9661.png

 

For each attack wave, only one type of sprite is used ( never a combination ). At most, 5 objects of the same type.

 

So each will become 24x24 px wide or 3x3 chars, that's total of 256 8x8 px characters but maybe less 1 char for the duplicate.

You also don't need access to all shapes on the screen since attack waves don't include different combinations of objects, so the required shapes can be copied to an active character set before an attack wave is generated.

 

image.thumb.png.32099876e58880f9f6a0e0078edef46c.png

 

 

Then also factor in the animations for all the explosions ( the same frames are used for enemy bullets once they expire and for the air mine once it expires too ) of the enemies too which are quite numerous. There are 10 frames of animation and at 72 bytes for each frame of animation, that's around 720bytes. But you can probably get this down to around ~400 bytes with some redundancy and smarter coding.

 

 

image.thumb.png.e009a2cc647c3effa8869946e5ba97fc.png

 

To throw a spanner into the works, multiple air mines mines can be deployed whilst enemy ships are still visible on the screen , and then of course there are the Manta's bullets and different varieties of enemy bullets as well.

 

image.thumb.png.8fb13c09529391f5035ff8b7092adc6e.png

 

Edited by shoestring
Link to comment
Share on other sites

1 hour ago, Philsan said:

Perhaps it would help if, like AtariBlast!, you'll use CAR cartridge format.

AtariBlast! runs on 64KB machines from a 1024KB cartridge (no need to buy a cartridge, CAR format files can be run from multicarts).

Keep up with the good work!

As great as Atari Blast is, the sprites in Uridium need four times of size. The mulitplexer in Atari Blast works, because there is always a distance between the moving objects. 

Link to comment
Share on other sites

And, btw. 

let's say , any animation has 5 animation steps. 

If you put that into time for one second, it means 5 fps. Or the fact that there is 10 vertical blanks from animation to animation. 

So while the PMg could scroll at 50 fps, the single moving object is not needed to adjust it to the scrolling screen. 

 

A whole attack wave could be done, using a cluster of 4x4 characters. Do the shift in one cluster , and re use the cluster for the count of enemies. If ships are crossing in the attack wave, two types of clusters were needed one moving forward , one moving backward (up/down) . There some slight clash might occure where thex cross. 

As the moving objects don't need any caring about the background, there is a lot CPU free for handling "optical fine tuning". 

 

Possibly one charset could be enough to handle it all. 

Link to comment
Share on other sites

7 hours ago, rensoup said:

The ST doesn't have hardware scroll out of the box, so that's to be expected from shoddy coders but you can still do decent stuff like RTG

 

 

The scrolling area is only about 100 lines high but I think it could have been better (although it may just have been a memory issue as I think the game ran in 512KB)... and with hardware scroll discovered later, it could have been fullscreen.

 

Back to the topic, modeE and software sprites is the way to go obviously ?. As usual mode4 doesn't provide any speed benefit (probably the opposite), and no color benefit. Perhaps a bit of mem saving ?

 

Yeah. not talking about Sync scrolling on ST here... ;) even for ST Uridium was bad...

Charmode helps for bullets... 1 STA to set bullets or 8x8 char vs more STA in bitmap mode... takes longer to clear even using collum clear only... and when using 2 screen Gameboy scrolling method (painting collum ahead while scrolling) you end up in 2x bitmap ram and you need to take care if you not hit those damned 4k ANTIC adressing limit etc etc... but yeah bitmap might be first try...

 

Link to comment
Share on other sites

6 hours ago, shoestring said:

 

Ah of course, well for the enemies here is an example Sprite sheet. 

 

Enemies fly higher, so they don't need to cast a shadow, they also do not collide with the player.

 

image.png.06e0d172df9258d47a76c2f5949f9661.png

 

For each attack wave, only one type of sprite is used ( never a combination ). At most, 5 objects of the same type.

 

So each will become 24x24 px wide or 3x3 chars, that's total of 256 8x8 px characters but maybe less 1 char for the duplicate.

You also don't need access to all shapes on the screen since attack waves don't include different combinations of objects, so the required shapes can be copied to an active character set before an attack wave is generated.

 

image.thumb.png.32099876e58880f9f6a0e0078edef46c.png

 

 

Then also factor in the animations for all the explosions ( the same frames are used for enemy bullets once they expire and for the air mine once it expires too ) of the enemies too which are quite numerous. There are 10 frames of animation and at 72 bytes for each frame of animation, that's around 720bytes. But you can probably get this down to around ~400 bytes with some redundancy and smarter coding.

 

 

image.thumb.png.e009a2cc647c3effa8869946e5ba97fc.png

 

To throw a spanner into the works, multiple air mines mines can be deployed whilst enemy ships are still visible on the screen , and then of course there are the Manta's bullets and different varieties of enemy bullets as well.

 

image.thumb.png.8fb13c09529391f5035ff8b7092adc6e.png

 

aehm... 3x3 is not enough to move them in pixel steps. so its more like 4x4 = 16x 5 = 80 chars alone for the enemies. not talking about bullets and other stuff like background ship yet... and that's off our lovely 128 char budget... As I said... that's the hardest part to think about. the sprite architecture. not the scrolling and mimic of the c64 layout... that will definitly become a dead end... believe me... been there... ;) 

 

 

Edited by Heaven/TQA
Link to comment
Share on other sites

Hi guys !
Jose asked me to do test on level image so here it is. As you see, with three charsets it comes down to max 102 chars needed for background gfx.
So let's say you have 26 chars left. In theory that's enough for 8 sprites (each 3 chars wide with shifting).
Not much left for anything else like bullets.
With two charsets it's even worse, 120 for one and 116 for second charset needed.

 

425075781_Screenshotfrom2020-11-1313-49-04.png.e270c09f18045d4d5c95c617509d33ca.png

 

Someone should just try simple bitmap as Rensoup said, maybe even double scanline mode like Zybex. Game won't suffer much as it's speed that's base of gameplay anyway.

I don't like looks of quad pms as Emkay proposed, but I can see validity in that idea if it were used for only filling space between details maybe...
 

In either way, I would forget of trying to copy 1:1 c64 gfx. Just make new game with new gfx, fast scroll and lot's of enemies.

 

 

Edited by popmilo
  • Thanks 1
Link to comment
Share on other sites

6 hours ago, popmilo said:

 

I don't like looks of quad pms as Emkay proposed, but I can see validity in that idea if it were used for only filling space between details maybe...
 

 

 

How to judge on things when there is no example at all.

Doing such a "PMg"-scrolling background, and to use the characters for the moving objects, needs only some CPU cycles. 

Also , the handling of it all has a linear usability to the coder. 

No need for a software based Gordian Knot for such a game. 

So there is a lot CPU left for optimizing speed and graphical details. 

 

 

 

 

 

 

Link to comment
Share on other sites

21 hours ago, shoestring said:

 

To throw a spanner into the works, multiple air mines mines can be deployed whilst enemy ships are still visible on the screen , and then of course there are the Manta's bullets and different varieties of enemy bullets as well.

 

 

Seems like you've just built a compelling case for not using char mode?

 

15 hours ago, Heaven/TQA said:

Yeah. not talking about Sync scrolling on ST here... ;) even for ST Uridium was bad...

Charmode helps for bullets... 1 STA to set bullets or 8x8 char vs more STA in bitmap mode... takes longer to clear even using collum clear only... and when using 2 screen Gameboy scrolling method (painting collum ahead while scrolling) you end up in 2x bitmap ram and you need to take care if you not hit those damned 4k ANTIC adressing limit etc etc... but yeah bitmap might be first try...

 

 

You still need to copy those chars before modifying them and you need to copy a larger area too to account for shifting on X and Y so all in all I doubt it's worth the hassle.

I don't think you need double RAM, I assume you mean a double width (for infinite hscroll) double buffer (for page flipping). You could just use a single width double buffer + 1 extra scanline per scrolling screen (ie 20 scanlines for a scrolling area 20 times the screen width). But yeah, there could be a tiny problem with the 4K limit.

 

12 hours ago, popmilo said:

 

Someone should just try simple bitmap as Rensoup said, maybe even double scanline mode like Zybex. Game won't suffer much as it's speed that's base of gameplay anyway.

 

 

Your favourite mode ?.

 

I believe it can be done at full height!

 

5 hours ago, emkay said:

 

How to judge on things when there is no example at all.

Doing such a "PMg"-scrolling background, and to use the characters for the moving objects, needs only some CPU cycles. 

 

 

Problem with that is you've used all your PMGs for background, so everything is going to be grey. Visually the original is already quite a mess...

 

Link to comment
Share on other sites

Honestly 20 years ago I discussed here the Zone Ranger “engine” for a time pilot port... (the Activision version) and still like it. I think A8 has its strength in bitmap mode (compared to char based C64 and sprite based). Bitmap modes are were the 6502 is not slowed as much down as in char mode with its DMA pemnalties ("badlines"). etc etc.

 

The A8 is a beauty for its linear flexible bitmap modes built 1978... 

 

but don’t let this thread going off topic. I just raised my hands in guys be careful in not thinking ahead how to mimic sprites of the C64... a scrolling char based background is nothing for the A8... compared to emulate 8 12x23 multicolor sprites...

 

and Uridium luckily doesn’t envolved color ram... or mix of highres and low res per char etc... ;) now as I think the game is very simple? Technically except the 50 fps for C64... and cramming all into those RAM.

 

ps. Jeeeez really nearly 20 years when joining AA... Facebook wasn’t born... kudos to Albert.

Edited by Heaven/TQA
  • Like 2
Link to comment
Share on other sites

19 hours ago, popmilo said:

Hi guys !
Jose asked me to do test on level image so here it is. As you see, with three charsets it comes down to max 102 chars needed for background gfx.
So let's say you have 26 chars left. In theory that's enough for 8 sprites (each 3 chars wide with shifting).
Not much left for anything else like bullets.
With two charsets it's even worse, 120 for one and 116 for second charset needed.

 

425075781_Screenshotfrom2020-11-1313-49-04.png.e270c09f18045d4d5c95c617509d33ca.png

 

Someone should just try simple bitmap as Rensoup said, maybe even double scanline mode like Zybex. Game won't suffer much as it's speed that's base of gameplay anyway.

I don't like looks of quad pms as Emkay proposed, but I can see validity in that idea if it were used for only filling space between details maybe...
 

In either way, I would forget of trying to copy 1:1 c64 gfx. Just make new game with new gfx, fast scroll and lot's of enemies.

 

 

 

 

 

Great little tool you got there. It gave me a little inspiration to write my own, but it's much less polished and sophisticated for now.

 

The amount of free characters does vary between different levels too, quite significantly too.

 

Character set summary for: zinc.png
Total unique shapes generated for chrset 0: 102
Total unique shapes generated for chrset 1: 88
Total unique shapes generated for chrset 2: 99

 

And then for Level 6 there's quite a big difference.

 

Character set summary for: gold.png
Total unique shapes generated for chrset 0: 112
Total unique shapes generated for chrset 1: 101
Total unique shapes generated for chrset 2: 107

Edited by shoestring
  • Like 1
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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