emkay Posted November 19, 2020 Share Posted November 19, 2020 7 hours ago, TIX said: Since the big ships look more or less identical in 2:2 Antic5 ratio (with little touch-up), lets concentrate on the sprites.. things are looking pretty good either way in my opinion ! With those examples you show what I was talking about 10 years ago. There is no real loss, if a double scanline mode is used. While it saves memory, some additional frames can give even more "live experience" to the gamplay. 2 Quote Link to comment Share on other sites More sharing options...
shoestring Posted November 20, 2020 Author Share Posted November 20, 2020 11 hours ago, José Pereira said: Here's level_1 in 4x1 that I think doesn't look all that bad (with an enemy at the left side): So black, white & grays more 2 on the enemy ship =6 Still 2 as PMG0&1 multicolour on our ship and one more left in GR.9... Jose has trouble accessing Atariage so has emailed me with some additional notes, and to pass this on in the thread. Quote GR.10 9 colours registers: our ship: PM0 white + PM1 dark pale E (glass)=yellow (multicolour); PM2: enemy shot (same as its dark colour luminance); PM3: its shadow dark gray (same as in gfxs) BAK: black; PF0: light gray; PF1: enemy ships light colour luminance; PF2: enemy ships middle colour luminance; PF3: coloured squares on the large ship; BAK black, PM1 dark gray and PF0 light gray can then change as is on C64 for other levels. The PMGs would be, of course, more detailed in 2:1 ratio. Also enemy ships explosion can be same ratio and a re-use of PM2 (if it was destroyed maybe 'clean' that line shot). Our ship shots, like is on C64, would be then maybe white. As in GR. 10 the borders are by PM0 register that in our case is white but also to have more visible playing area than better going to 48 bytes wide screen. We'll also not include stars on the large ships scanlines as they would look ugly in 4:1 ratio but only on the up and down of them maybe in 3 'shining' colour using GR.15 bitmap mode 2:1 ratio. Maybe even 'blinking' would make a nice effect. On C64 also enemies and our ship seems to not go to these scanlines. 1 1 Quote Link to comment Share on other sites More sharing options...
emkay Posted November 20, 2020 Share Posted November 20, 2020 6 hours ago, shoestring said: Jose has trouble accessing Atariage so has emailed me with some additional notes, and to pass this on in the thread. Why now bothering with graphics 10? People blame the lower scrolling resolution of horizontal 160 pixel, and now turn even down to 80 pixel? And then there is the GRPIOR that doesn't allow to use all PMg over the graphics, as the colors of the PMg itself were acting in GPRIOR with the background colors starting at 704... Quote Link to comment Share on other sites More sharing options...
José Pereira Posted November 20, 2020 Share Posted November 20, 2020 (edited) 4 hours ago, emkay said: Why now bothering with graphics 10? People blame the lower scrolling resolution of horizontal 160 pixel, and now turn even down to 80 pixel? And then there is the GRPIOR that doesn't allow to use all PMg over the graphics, as the colors of the PMg itself were acting in GPRIOR with the background colors starting at 704... I thought in that but really had a mistake on my colours distribution so here's them fixed: 11 hours ago, shoestring said: GR.10 has 9 colours registers: our ship: PM0 pale green (EA) + PM1 dark pale (E4) (glass)= yellow (EE) (multicolour); PM2: enemy shot (same as its dark colour luminance); PM3: ours ship shadow dark gray (also on gfxs and shadows of them); BAK: black; PF0: white (also on gfxs, enemys and our ship shots); PF1: light gray (also on gfxs); PF2: enemy ships middle colour luminance; PF3: coloured squares on the large ship; BAK black, PM3 dark gray and PF1 light gray can then change as is on C64 for other levels. The PMGs would be, of course, more detailed in 2:1 ratio. Also enemy ships explosion can be same ratio and a re-use of PM2 (if it was destroyed maybe 'clean' that line shot). Our ship shots, like is on C64, would be then maybe white. As in GR. 10 the borders are by PM0 register that in our case is white but also to have more visible playing area than better going to 48 bytes wide screen. We'll also not include stars on the large ships scanlines as they would look ugly in 4:1 ratio but only on the up and down of them maybe in 3 'shining' colour using GR.15 bitmap mode 2:1 ratio. Maybe even 'blinking' would make a nice effect. On C64 also enemies and our ship seems to not go to these scanlines. Also will look better large ships be in 4:2 then the enemys in 4:1 ratio while our ship and its shadow be in 2:1 ratio PMGs: And just a piece of it for you seeing better with need to 'zooming' it: I think it could look nice and would be a new 'way of'... Now @emkay there's only one thing there (just a pixel) that doesn't work with priority that is Prior_1 to be used... Guess what is it? Clues: Our ship is PMGs so goes over all gfxs whatever they are (there's only a PMG register PMG3 on gfxs) and also enemy ships are just PFs and soft sprite 'bitmap masking' over large ship gfxs so no problem and theirs shots are PMG2 so always over whatever. But that pixel can have a simple solution just enebling an A8 Hardware register . Where's the Wally? Edited November 20, 2020 by José Pereira Forget solution by using a Hardware register (it'll be used for other thing...). Yes, still remains that just single pixel but could not be all that important and workable. 1 Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted November 20, 2020 Share Posted November 20, 2020 1 hour ago, José Pereira said: And just a piece of it for you seeing better with need to 'zooming' it: I think it could look nice and would be a new 'way of'... Gotta say this is starting to look too low res now, the details don't really look 3d any more. Dropping the vertical white highlights has really lost something. 2 Quote Link to comment Share on other sites More sharing options...
TIX Posted November 20, 2020 Share Posted November 20, 2020 (edited) 56 minutes ago, Mr Robot said: Gotta say this is starting to look too low res now, the details don't really look 3d any more. Dropping the vertical white highlights has really lost something. It's a huge ship, I don't see why we can't have vertical white highlights.. it just needs some love ! ..looking for a way to draw the little diamond shaped thingies ! edit: done ? Edited November 20, 2020 by TIX 3 1 Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted November 20, 2020 Share Posted November 20, 2020 That's much better, could the dark grey be one more shade darker? Also add one more line of dark at the beginning of the narrow neck to make it look more like the is height there. Here's a thought, if the verticals are that thick, what does it look like if the horizontals are two pixels wide? It will probably be too much but worth a try. Quote Link to comment Share on other sites More sharing options...
emkay Posted November 20, 2020 Share Posted November 20, 2020 3 hours ago, TIX said: It's a huge ship, I don't see why we can't have vertical white highlights.. it just needs some love ! ..looking for a way to draw the little diamond shaped thingies ! edit: done ? You know the problem? What you see in the picture has nothing to do with the Atari's hardware. To have any separated colored moving object over the ship, you'd need to use playfield colors, so you're restrictes to 80 pixel width based software sprites. You cannot set colored PMg over the ship in GTIA 10, as the colors are a part of the background. You could do some trickery using Playfield color 4 (711) and the missiles active set to one color. Quote Link to comment Share on other sites More sharing options...
popmilo Posted November 20, 2020 Share Posted November 20, 2020 Really @José Pereira why wide pixels ? You know I love them, but don't understand the need 1 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted November 20, 2020 Share Posted November 20, 2020 Let's really save some CPU time. We don't get too many ANTIC mode 8 games! 1 17 Quote Link to comment Share on other sites More sharing options...
miker Posted November 21, 2020 Share Posted November 21, 2020 On 11/10/2020 at 3:30 PM, shoestring said: I've also made some changes to the RMT as well, I think it sounds a little better now. uridium-sketch.v1.3.rmt 1.67 kB · 12 downloads Has emkay shared his version of this tube? I think he should. I don't need to be credited here, just had some 15 mins fun on this. Quote Link to comment Share on other sites More sharing options...
shoestring Posted November 21, 2020 Author Share Posted November 21, 2020 52 minutes ago, miker said: Has emkay shared his version of this tube? I think he should. I don't need to be credited here, just had some 15 mins fun on this. He shared the previous version, 1.2. But I’m sure someone can do better than this. It would be nice with some drums but I couldn’t find a way to make the bass channel sound decent after splitting it. Quote Link to comment Share on other sites More sharing options...
+mytek Posted November 21, 2020 Share Posted November 21, 2020 16 hours ago, Stephen said: Let's really save some CPU time. We don't get too many ANTIC mode 8 games! Better yet, let's hookup 8 of these in parallel and really kick ass in Mode 8 with 8 colors, 8X Players and Missiles, and essentially an 8 core CPU! However one small but significant problem - we'd also need an OS capable of working with parallel processors . One can always dream. Sorry for the off topic... carry on. 1 2 Quote Link to comment Share on other sites More sharing options...
shoestring Posted December 10, 2020 Author Share Posted December 10, 2020 I had a bit of a set back a couple of weeks ago and lost everything in a HD crash, yup.. my own fault. That includes source code for the A8 diagnostic software I wrote and all my arcade related stuff. So I had to start this project virtually from scratch and then use the xex I uploaded here to disassemble/reverse engineer what I did which helped me get back up to speed and on track rather quickly. I now have the Manta's bullets working ( using soft sprites ) in the attract mode with collisions to objects in place ( that includes destruction of parked ships and collisions to the obstacles on it ). Though that didn't take much work because the original game uses soft sprites for the players bullets as well. Uridium.atr Uridiump.xex 6 Quote Link to comment Share on other sites More sharing options...
rensoup Posted December 10, 2020 Share Posted December 10, 2020 Just reread the first post I didn't realize you were porting the c64 code at first... so I guess it would be a mess to make major changes to the graphics mode... well I'm curious how you're going to tackle the sprites Quote Link to comment Share on other sites More sharing options...
rensoup Posted February 7, 2021 Share Posted February 7, 2021 more indieretronews: http://www.indieretronews.com/2020/12/this-unreal-engine-4-remake-of.html#more Uridium on Unreal4 engine... look pretty much the same ? Quote Link to comment Share on other sites More sharing options...
emkay Posted February 7, 2021 Share Posted February 7, 2021 18 minutes ago, rensoup said: more indieretronews: http://www.indieretronews.com/2020/12/this-unreal-engine-4-remake-of.html#more Uridium on Unreal4 engine... look pretty much the same ? Outmost very heavy understatement of the engine Quote Link to comment Share on other sites More sharing options...
rensoup Posted February 8, 2021 Share Posted February 8, 2021 Had to do a sprite test... perf wise, it seems doable but probably not in 64KB spritetest.obx 7 Quote Link to comment Share on other sites More sharing options...
zbyti Posted February 8, 2021 Share Posted February 8, 2021 8 minutes ago, rensoup said: Had to do a sprite test... Very nice mothership! 6 Quote Link to comment Share on other sites More sharing options...
rensoup Posted February 9, 2021 Share Posted February 9, 2021 1 hour ago, zbyti said: Very nice mothership! courtesy of Tix ? Quote Link to comment Share on other sites More sharing options...
+Stephen Posted February 9, 2021 Share Posted February 9, 2021 2 hours ago, rensoup said: Had to do a sprite test... perf wise, it seems doable but probably not in 64KB spritetest.obx 31.49 kB · 7 downloads That's beautiful! 2 Quote Link to comment Share on other sites More sharing options...
Materion Posted March 20, 2021 Share Posted March 20, 2021 This demo looks very promising :). Keep good job up Quote Link to comment Share on other sites More sharing options...
Yautja Posted July 2, 2021 Share Posted July 2, 2021 On 12/9/2020 at 10:18 PM, shoestring said: I had a bit of a set back a couple of weeks ago and lost everything in a HD crash, yup.. my own fault. That includes source code for the A8 diagnostic software I wrote and all my arcade related stuff. So I had to start this project virtually from scratch and then use the xex I uploaded here to disassemble/reverse engineer what I did which helped me get back up to speed and on track rather quickly. I now have the Manta's bullets working ( using soft sprites ) in the attract mode with collisions to objects in place ( that includes destruction of parked ships and collisions to the obstacles on it ). Though that didn't take much work because the original game uses soft sprites for the players bullets as well. Uridium.atr 179.64 kB · 24 downloads Uridiump.xex 21.24 kB · 39 downloads Any news on this project? ? 1 Quote Link to comment Share on other sites More sharing options...
shoestring Posted July 2, 2021 Author Share Posted July 2, 2021 (edited) Progress is rather slow at the moment. There's a lot happening right now, I should have more time with yet another lockdown but then work has gone crazy too with the number of security breaches and requirements at work. I have converted the project to run on VBXE which is something I've been considering and exploring since the beginning, keeping the mode 2 screen with bitmap overlay for bobs. There really was no way to utilise a screen with interleaved character sets ( per level x 15 ) and still have enough left over/vacant positions for software sprites. Maybe a better coder can find a way without too much compromising?. Also factoring in that you have to facilitate additional shapes for objects on the platform that have been destroyed and the 2 unique star shapes, all previously overlooked when looking at this initially. Consider Zinc ( level 1 ) where I have undamaged tiles adjacent to their respective damaged ones, when this is run through my interleave util, I'm barely left with anything. Memory is another issue, with lack of DRAM access under the I/O.. but this alone wouldn't solve my overall problem. Currently in it's state, the game is somewhat playable but very very much unfinished. Options screen is responding to joystick input, some of these currently have no affect ( volume for example ). The last two weeks or so, building and working on the Sprite engine for the Manta, the Bullets are somewhat complicated.. but will go back in place once I get the overlay working fully as I'm now using BCBs to copy the bullets across all character sets [ in case the manta moves up or down the screen ]. There are ~12 frames just for bullets in each character set, and this changes based on the Manta's orientation, it can fly sideways and roll about its horizontal axis whilst shooting bullets. Manta responds to left and right on the joystick, but no up and down yet, shadow is cast but it's all still very glitchy.... though I suspect this is to do with the bad synchronization of the bob ( sprite frame and x/y coords in the BCB) updates which I'll look at shortly. The bulk of my time has been spent decoding what I call "bg object data" and creating visuals in charpad to represent them. This helps me locate and make the relevant changes to the actual data for each charset when relocating a shape or tile to a different position ( since I'm now working with 128 per sheet ). So for example runways data is 5 columns, 3 bytes each which represent a position in the character set. ;================================ Struct 17 ; Runway objects 1 ; .byte 05,03 ; 5 columns, first column is 3 x 8 pixels in height .byte 14,55,13 ; Column #42 .byte 03 .byte 14,55,13 ; Column #43 .byte 03 .byte 14,55,13 ; Column #44 .byte 03 .byte 14,55,13 ; Column #45 .byte 03 .byte 14,55,13 ; Column #46 This is very time consuming process and so far almost completed Gold ( and still 14 more to verify ) before taking a look at how I'd implement the Sprite engine and test it out as an overlay. I've had to re-arrange shapes in each charset , especially for the collision detection to work seamlessly ( objects you can destroy, obstacles you can run into ..etc ), not enabled currently. For some reason some black random dots ( that don't seem to be turned on in VBXE ram ) have started appearing once I enabled the bob overlay which aren't present on the screen on the real hardware, so I'm hunting a bug somewhere that Altirra is picking up, any VBXE programmers have any clues ?. Maybe this weekend I can find the time to look at it more. test sprites.avi gold.avi Edited July 2, 2021 by shoestring 7 1 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted July 2, 2021 Share Posted July 2, 2021 You take your time Shoestring, work and real life before anything else.. Sounds like it's turned into a big project.. Best of luck figuring it all out.. Paul.. 2 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.