Uridium demo.

[Mclaneinc]

Loving the collaboration between programmers here, so nice to see..

[Gunstar]

On 11/5/2020 at 1:22 PM, emkay said:

 

River Raid is from 1982. 

There is a small airplane, needing to fly rather low, to shoot ships. There is gravity, there is limited hardware. So everything is in a range of acceptability.

 

Uridium is from 1986. 

There is a Saucer flying in Space, the angle of attack can be 360 degree  from all sides. There is no gravity the used hardware is far less limited.  So it makes no sense at all. 

Remember Star Raiders ?

Back then the machines didn't have the ability to do anything in space except for start fields and a few sprites! How exactly are you going to do a huge mother ship in 3D on 8-bit hardware? I don't recall any 3D mother ships you attack in Star Raiders. Besides, they are VIDEO GAMES you stupid git! Seen any Pac-man's roaming around the streets lately? It takes just as much imagination and suspension of disbelief to play River Raid as any other video game of the day.

 

That being said, it would be great to see some new Star Raiders or Rescue on Fractalus type flying 3D shooter, in space or planet side...even some Rapidus/VBXE 3D would open my pocket-book to finally getting those upgrades.

[Gunstar]

On 11/6/2020 at 1:06 AM, emkay said:

My words are only keeping some truth. Also your recognition "emkay spreads negativity to every single one" is your own.

 

Imagine I'd click the ignore button to this thread.

Some C64 guy surfs the internet, and reaches the line "Uridium Demo for the Atari 8 bits". 

He immediately goes there. Then, what does he find?

A remake of the title, and some scroller that hangs after a while, not even a completely running demo. 

After you made his day, he moves on ...

 

 

 

I had you on ignore for quite a while, but I found I actually missed your idiotic trolling to make me laugh, sort of like a troll mascot for AA,,,

[Gunstar]

On 11/6/2020 at 3:44 PM, Stephen said:

There's a common denominator here, and it is neither I, nor Mclenic that are the issue.

 

Seems to happen every few weeks too.  Non-coder who hasn't released anything but RMT tunes, many of them horribly out of tune, constantly tells other people what can and cannot be done.  Puts down every effort by people.  Then wonders why we don't get more new software.  Projects his issues onto everyone else.  I really wonder what his mental issue is because it seems to be more than just being an asshole.

I tried a couple of Emkays RMT releases and I could not agree with you more. They hurt my ears. I don't think anyone could possibly compose worse, except maybe for myself!

Edited November 14, 2020 by Gunstar

[Heaven/TQA]

well... beside the trolling.... did not the coders noted.... beware... sprites are key?  

[popmilo]

16 minutes ago, Heaven/TQA said:

well... beside the trolling.... did not the coders noted.... beware... sprites are key?  

Really Shoestring, do you have idea on how to do sprites ?

 

 

[shoestring]

We have sprites? Mmmm.... sprites in the border

[emkay]

41 minutes ago, popmilo said:

Really Shoestring, do you have idea on how to do sprites ?

 

 

You should ask Atariage's ultimate troika. 

McLaneinc. , Stephen , and Gunstar. They are so sure to judge over my knowledge about the Atari, so they know it all and can do it better. I'm pretty sure they will find the solution. 

Edited November 14, 2020 by emkay

[shoestring]

2 hours ago, Heaven/TQA said:

well... beside the trolling.... did not the coders noted.... beware... sprites are key?  

Notes were taken. Sorry, I’m not ignoring you. I just don’t always have time to respond to every reply in the thread.

Edited November 14, 2020 by shoestring

[LarsImNetz]

Please, take a look

 

[emkay]

8 hours ago, LarsImNetz said:

Please, take a look

 

 

To resemble the gameplay of Uridium, you'd have to make the enemies 4 times bigger, and to add the attack wave formations. 

In short: 8 times more CPU speed needed for  a multiplexer. 

[shoestring]

On 11/14/2020 at 1:55 PM, rensoup said:

 

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

 

Yep it doesn't look promising at all, just 6 sprites spawned belonging to foes ( that includes a combo of enemies, bullets & air mines  ) pretty much blows the budget. 

 

If my calcs from last night are correct I'd need ~115 free per char set to fit it all into 01-Zinc, impossible.. and consider that every level has different requirements. So it's a minimum of 96 or so spare characters just for 6 sprites, not including frames for the enemy explosions, the two glyphs used for stars behind the dreadnought which aren't a big deal but still that's less two. Several characters are also required for the player's bullets, these move 2 character widths at a time and are character aligned. 

 

Would be much better off using one of the bitmap modes and writing an original game from scratch but with so many similar shooters, I'd have to think about what it would have to offer before I even go there. The other optionis looking into the feasibility of converting this to a VBXE project.

 

[popmilo]

4 hours ago, shoestring said:

Yep it doesn't look promising at all, just 6 sprites spawned belonging to foes ( that includes a combo of enemies, bullets & air mines  ) pretty much blows the budget. 

 

If my calcs from last night are correct I'd need ~115 free per char set to fit it all into 01-Zinc, impossible.. and consider that every level has different requirements. So it's a minimum of 96 or so spare characters just for 6 sprites, not including frames for the enemy explosions, the two glyphs used for stars behind the dreadnought which aren't a big deal but still that's less two. Several characters are also required for the player's bullets, these move 2 character widths at a time and are character aligned. 

 

Would be much better off using one of the bitmap modes and writing an original game from scratch but with so many similar shooters, I'd have to think about what it would have to offer before I even go there. The other optionis looking into the feasibility of converting this to a VBXE project.

 

I would try it with bitmap mode and unrolled soft sprite code. All enemies are one shape at the time so it could be pretty fast. And 4 colors wouldn't matter.

 

Vbxe would at least be "exclusive". And could be good show of what's possible with it. Owners of vbxe would be happy for sure. Rest of us ? Who cares, we can watch on youtube or play in Altirra

 

 

[popmilo]

Message from Jose:

@shoestring:
I think it can maybe in charmode.
In CharPad is all maps 17charlines tall.
My idea is add 2 on top and more 2 at the bottom to have all 21 so
multiple of 3 interleaved.
Enemys reduced to [9x17] that with shifting/for their movent is
[3x3]chars so 5enemys are 15chars per charset more our ship bullets
but for this I have an idea.
What I need is time to put all maps 21chars high but also all same
colours: black, white and 2grays becauso Vlad's extract program can't
deal them changing colours.
Just give me next week as I'm also with an idea for have enemys
different main colour over large ship other main colour. Just some
changes on gfxs on wich PFs are on them.
Maybe some days more.
Keep safe.

[Gunstar]

18 hours ago, emkay said:

You should ask Atariage's ultimate troika. 

McLaneinc. , Stephen , and Gunstar. They are so sure to judge over my knowledge about the Atari, so they know it all and can do it better. I'm pretty sure they will find the solution. 

Unlike you, I reserve judgment on everything until I see it in completed form, and I stay within my knowledge boundaries unlike you. I don't know anything about it, just like you.

[emkay]

1 minute ago, Gunstar said:

Unlike you, I reserve judgment on everything until I see it in completed form, and I stay within my knowledge boundaries unlike you. I don't know anything about it, just like you.

So, why don't you shut up anyways?

[Gunstar]

4 minutes ago, emkay said:

So, why don't you shut up anyways?

I did, you dragged me back in with your usual hilarious and idiotic comments, specifically naming me. But you just keep on making your noise, I'm getting a real laugh out of it all!

Edited November 15, 2020 by Gunstar

[emkay]

1 minute ago, Gunstar said:

I did, you dragged me back in with your idiocy.

 

It's not my idiocy, it's yours. Because you only think to know what I know and act on that. You seem evenly not able to read your own language and put insults on that.  And that a long time after the things have been finished.

I only feel sorry for you. 

[jaybird3rd]

Enough bickering, please.  If you must continue to trade insults, take it to PM.

[www.atarimania.com]

 

[rensoup]

11 hours ago, shoestring said:

Would be much better off using one of the bitmap modes and writing an original game from scratch but with so many similar shooters, I'd have to think about what it would have to offer before I even go there. The other optionis looking into the feasibility of converting this to a VBXE project.

I believe a (almost) 1:1 conversion might be doable in bitmap mode, it'd be a shame to make it a VBXE only project. (The main difference would be the enemy ship colors which could be enhanced with multiplexed PMGs in PRIOR0 ?)

 

Not sure why you wanted to go with char mode ? 

 

Like others have said, the issue is to display all those sprites, so that'd be the first thing to figure out. Since the 5 enemies are identical, you may be able to load the bitmap once and plot it 5 times which would half the CPU cost. Thrown in precompiled sprites and you may have a good shot... It'd be a big job and require a lot of memory though.

 

[shoestring]

1 hour ago, rensoup said:

I believe a (almost) 1:1 conversion might be doable in bitmap mode, it'd be a shame to make it a VBXE only project. (The main difference would be the enemy ship colors which could be enhanced with multiplexed PMGs in PRIOR0 ?)

 

Not sure why you wanted to go with char mode ? 

 

Like others have said, the issue is to display all those sprites, so that'd be the first thing to figure out. Since the 5 enemies are identical, you may be able to load the bitmap once and plot it 5 times which would half the CPU cost. Thrown in precompiled sprites and you may have a good shot... It'd be a big job and require a lot of memory though.

 

Convenience and simply overestimated, overlooked the ability of the machine to be able to deal with the number of characters I would really need. But with my new python tool I can clearly see that a 1:1 pixel translation isn’t going to be feasible without resizing the Sprites. 

 

Someone mentioned antic E but then it  becomes a different game, doesn’t it ? With half the horizontal resolution and only 4 colours for the playfield, maybe more with PMG but then you’d like to prioritise those for the manta.  Mode F is better..  everything can be 1:1 but it lacks the sparkle and those huge memory requirements for both modes are prohibitive. Looks unlikely with just 64kb

 

 

[José Pereira]

Idea is to put all in monograys together then extract all 3 interleaved charsets

Edited November 16, 2020 by José Pereira
For 3 interleaved multiples added to each map 'stars part' 2charlines top + 2 bottom. To @Popmilo program works must be same colours, in code will just change PFs. In a day or two all to really see how many chars each have...

[rensoup]

16 hours ago, shoestring said:

Someone mentioned antic E but then it  becomes a different game, doesn’t it ? With half the horizontal resolution and only 4 colours for the playfield, maybe more with PMG but then you’d like to prioritise those for the manta.  Mode F is better..  everything can be 1:1 but it lacks the sparkle and those huge memory requirements for both modes are prohibitive. Looks unlikely with just 64kb

 

I did mention modeE indeed (I always do, I find it to be the most versatile mode) but I think you got it confused with another mode because modeE is the same as mode4 in terms of resolution (width is 160) and yes it's 4 colors but that's the same as Uridium right ? (white - light grey - dark grey -black) 

 

Regarding memory, it would be expensive but 64kb might be doable... 

 

For a soft sprite, an optimistic cycle count would be 8 cycles/4 pixels * 6 (24 pixels width) * 21 lines = 1008 cycles for plotting a single sprite.

Then you need to restore the background : 12 * 6 * 21 = 1512 cycles  or perhaps 12* 5 * 21 = 1260 cycles.

 

So that's about 2500 cycles per sprite.

 

You may be able to dodge saving the background by maintaining a 3rd backbuffer. If you can't, it would be really tight to fit in a PAL frame (about 20000-22000 cycles)

 

Looking at those numbers, it is impossible without precompiled sprites. 

 

 

[popmilo]

3 hours ago, rensoup said:

I did mention modeE indeed (I always do, I find it to be the most versatile mode) but I think you got it confused with another mode because modeE is the same as mode4 in terms of resolution (width is 160) and yes it's 4 colors but that's the same as Uridium right ? (white - light grey - dark grey -black) 

 

Regarding memory, it would be expensive but 64kb might be doable... 

 

For a soft sprite, an optimistic cycle count would be 8 cycles/4 pixels * 6 (24 pixels width) * 21 lines = 1008 cycles for plotting a single sprite.

Then you need to restore the background : 12 * 6 * 21 = 1512 cycles  or perhaps 12* 5 * 21 = 1260 cycles.

 

So that's about 2500 cycles per sprite.

 

You may be able to dodge saving the background by maintaining a 3rd backbuffer. If you can't, it would be really tight to fit in a PAL frame (about 20000-22000 cycles)

 

Looking at those numbers, it is impossible without precompiled sprites. 

 

 

Why is your math like that ?
Shouldn't restoring background be faster than drawing masked sprite ?

 

"24 pixels width" - you mean hires pixels ? So 3 bytes like c64 sprites ?

 

Imho drawing is like:

21 line x 4 bytes (4th is for shift) x (lda+and+ora+sta = 5+5+5+6 = 21) = 1764

Restore would be simple lda+sta: 21x4x(5+6)=924

So even worse than your calc...

 

That would be tight indeed... 3 buffers is something I never tried on 8bit, probably because of memory needed Although it would be only around 20kb in atari case... And most of the time all sprites move so wouldn't make much difference maybe.

 

At least calculation like this shows that chances of something like this working on A8 is much higher with double scanline mode

Somebody will code it, and we'll see what can be done