Jump to content
IGNORED

WIP : Nitrous


Sporadic

Recommended Posts

8 hours ago, SlidellMan said:

Looks better than before. Here's a little something in return:

I look forward to seeing my logo in the final game. You can credit me.

 

While I appreciate anyone wanting to create graphics for my games, as I said previously, don't create any artwork unless I've requested it. There's colour and size restrictions, not to mention style. I don't want anyone wasting their time making things I won't use.

  • Like 1
Link to comment
Share on other sites

51 minutes ago, agradeneu said:

Getting better and better! Some nitpicking: Is it possible to make the horizon line a bit higher? For a racing game, I would like to have a bit more road, but maybe that is just me. ;-)

Cheers!

 

The horizon is a balancing act between visuals and performance. It's dancing close to the max frame time already. Changing over to the lateral road movement has used up my last round of performance gains.

I'm always tweaking and trying to improve performance though (hence partly why the game is taking the time it is) and expanding the road is always on the list.

  • Like 3
Link to comment
Share on other sites

5 hours ago, life-among-bits said:

Hey, hi people, YouTube algorithm brought me here.

@Sporadic, when will be available a version besides the 2015 in the first post here?

I want to make a video about it, real impressive. By the way, that jump thing reminds me Top Gear 3000, love it!

Hi and thanks for the feedback!

It doesn't have a release date yet and will still be quite a while.

I do want to start posting more updates/videos as it progresses though.

  • Like 3
Link to comment
Share on other sites

  • 5 months later...
10 hours ago, neogeo1982 said:

Liked the camera update video on Youtube?. Any more recent updates or videos?

No more updates since the last one, unfortunately. I've had a busy year and not been able to focus on this too.

 

I did manage to knock the last few items off my list for Crumbs last week though :D

 

  • Like 5
Link to comment
Share on other sites

  • 3 weeks later...
  • 1 month later...
On 5/11/2018 at 2:08 PM, Sporadic said:

It's been quite a while since I posted an update on this, so here goes;

 

Changes since last update;

- New full Blitter drawn road and scenery.

- Bridges and Tunnels.

- Jumps.

- Rivers.

- Manual or Automatic gears.

- Rain and snow.

- Moar colours.

- Revs/speedo.

 

I am still actively working on it, just been trying to get to a stage i'm happy with to share a new video.

 

The video below shows a drive through one of the possible routes.

 

Please keep in mind that all art/sound assets are still placeholders and the tracks are all under construction.

 

 

 

 

 

Why not use the Object Processor for know work load per scanline stuff? Like horizon and road.
For the scenery, how do you code the blitter to do transparency? Is it about functions, or patterns?

  • Confused 3
Link to comment
Share on other sites

4 hours ago, ArneCRosenfeldt said:

Why not use the Object Processor for know work load per scanline stuff? Like horizon and road.
For the scenery, how do you code the blitter to do transparency? Is it about functions, or patterns?

Ah thank you. Now I understand that the 16 bit "pattern data" register is indeed a color key. So with the blitter, but not the ObjectProcessor, you can have CRY sprites with transparency. You can select to compare the pattern value with the source xor the destination value to position "sprites" in front or behind the background.

The documentaton says: "performed one phrase at a time in .. sixteen bit per pixel modes" . So this is fast

  • Confused 2
Link to comment
Share on other sites

  • 8 months later...
On 7/8/2016 at 2:37 AM, Sporadic said:

Cheers, I'll keep it in mind

I’d be willing to assist with the pixel art, @Sporadic. When the time comes, just tell me the sprite size, resolution and the palette needed for NotOutRun, and I will get to work on things.

 

It could be a year after I made this post and I will still be happy to assist. Let me know via DM when you are ready for my assistance.

Edited by ColecoGamer
Link to comment
Share on other sites

  • 2 weeks later...
On 10/11/2022 at 8:21 PM, ColecoGamer said:

I’d be willing to assist with the pixel art, @Sporadic. When the time comes, just tell me the sprite size, resolution and the palette needed for NotOutRun, and I will get to work on things.

 

It could be a year after I made this post and I will still be happy to assist. Let me know via DM when you are ready for my assistance.

Why would we use pixel art on a (pseudo) 3d game. From the video it looks that the blitter cannot load a tiny amount of the RAM of the Jag anyway: Pixel mode is limited by output size, not input size. This is entirely dictated by the 3d part. You could even load some scenery from ROM or decompress in Jerry. Note how in Outrun objects repeat for a while, then a new bunch comes up. People in this forum told be that they never felt limited by cartridge size in their homebrew projects. I wonder why there is a JagCD then. Only for the FMV aparently. Have you guys seen the pseudocode for DCT (de-)compression? Like 20 adds, 10 copies, and two mults. I wonder why on the Jag mul is as fast as add and copy. I would (additionally) need a long instruction word (64bit) like the i750 from 1987 with 4 add and copy instructions on packed 64 bit registers. Ah, where was I ? Ah, yeah, why not use polygon models for the vehicles if you think that RAM is a limit? Than you can turn them in real time.

Ah, I see, the sprites snap to fixed scales. So sprites saturate to 1:1 scale for a good fill rate. But then again for the largest sprites the OP scaling would be a good fit. In the video like 10% of the pixels are touched by the blitter? Dirty rectangles and some OP magic ( interrupts -> GPU ). I thought the floor in this game is rendered to a frame buffer .. or is it full Super BurnOut with render to linebuffer already? Those sprites are huge!

Edited by ArneCRosenfeldt
  • Confused 13
Link to comment
Share on other sites

7 minutes ago, ArneCRosenfeldt said:

Why would we use pixel art on a (pseudo) 3d game. From the video it looks that the blitter cannot load a tiny amount of the RAM of the Jag anyway: Pixel mode is limited by output size, not input size. This is entirely dictated by the 3d part. You could even load some scenery from ROM or decompress in Jerry. Note how in Outrun objects repeat for a while, then a new bunch comes up. People in this forum told be that they never felt limited by cartridge size in their homebrew projects. I wonder why there is a JagCD then. Only for the FMV aparently. Have you guys seen the pseudocode for DCT (de-)compression? Like 20 adds, 10 copies, and two mults. I wonder why on the Jag mul is as fast as add and copy. I would (additionally) need a long instruction word (64bit) like the i750 from 1987 with 4 add and copy instructions on packed 64 bit registers. Ah, where was I ? Ah, yeah, why not use polygon models for the vehicles if you think that RAM is a limit? Than you can turn them in real time.

Ah, I see, the sprites snap to fixed scales. So sprites saturate to 1:1 scale for a good fill rate. But then again for the largest sprites the OP scaling would be a good fit. In the video like 10% of the pixels are touched by the blitter? Dirty rectangles and some OP magic ( interrupts -> GPU ). I thought the floor in this game is rendered to a frame buffer .. or is it full Super BurnOut with render to linebuffer already? Those sprites are huge!

Because 3D models would look like compete bollocks and isn't the art direction I'm going for.

I'm already decompressing assets from ROM in realtime between stages too and this is more like 90% drawn by the blitter with no "OP magic" and written in BASIC (with the awesome Raptor backend), so yeah, thanks for your ever valuable input to the forum.

Please go and numberwang someone else's video.

  • Like 6
Link to comment
Share on other sites

Just now, Sporadic said:

Because 3D models would look like compete bollocks and isn't the art direction I'm going for.

I'm already decompressing assets from ROM in realtime between stages too and this is more like 90% drawn by the blitter with no "OP magic" and written in BASIC (with the awesome Raptor backend), so yeah, thanks for your ever valuable input to the forum.

Please go and numberwang someone else's video.

But why do you go for this popping art style instead of fluent zoom? So where does all the memory go then? If you let zoom snap to some factor, you could also let rotation snap. Far away the small objects could rotate and you could have some twist in your roads. Thanks to your camera the rotation close to it snaps to zero to let OP deal with them. I mean, something to have beyond Super Burnout?

  • Confused 10
Link to comment
Share on other sites

3 minutes ago, ArneCRosenfeldt said:

But why do you go for this popping art style instead of fluent zoom? So where does all the memory go then? If you let zoom snap to some factor, you could also let rotation snap. Far away the small objects could rotate and you could have some twist in your roads. Thanks to your camera the rotation close to it snaps to zero to let OP deal with them. I mean, something to have beyond Super Burnout?

Do you think I've been working on this game (on and off) for nearly 7 years and not tried 20 different ways to render the road and scenery? I've had OP rendered scenery, scaled and mipmapped, Blitter drawn scenery scaled and mipmapped and other combinations in between such as blitter and OP scenery.

 

I'm creating this from a high level language as efficiently as possible while integrating with Raptor for the low level stuff. Yes, if this was pure ASM I'd have a lot more freedom with design choices but I have to go with what works while keeping a decent frame rate.

 

When you're driving, playing the game the scenery scaling method isn't as noticeable and it's a decision consciously made to help the frame rate.

  • Like 3
Link to comment
Share on other sites

8 hours ago, ArneCRosenfeldt said:

Why would we use pixel art on a (pseudo) 3d game. From the video it looks that the blitter cannot load a tiny amount of the RAM of the Jag anyway: Pixel mode is limited by output size, not input size. This is entirely dictated by the 3d part. You could even load some scenery from ROM or decompress in Jerry. Note how in Outrun objects repeat for a while, then a new bunch comes up. People in this forum told be that they never felt limited by cartridge size in their homebrew projects. I wonder why there is a JagCD then. Only for the FMV aparently. Have you guys seen the pseudocode for DCT (de-)compression? Like 20 adds, 10 copies, and two mults. I wonder why on the Jag mul is as fast as add and copy. I would (additionally) need a long instruction word (64bit) like the i750 from 1987 with 4 add and copy instructions on packed 64 bit registers. Ah, where was I ? Ah, yeah, why not use polygon models for the vehicles if you think that RAM is a limit? Than you can turn them in real time.

Ah, I see, the sprites snap to fixed scales. So sprites saturate to 1:1 scale for a good fill rate. But then again for the largest sprites the OP scaling would be a good fit. In the video like 10% of the pixels are touched by the blitter? Dirty rectangles and some OP magic ( interrupts -> GPU ). I thought the floor in this game is rendered to a frame buffer .. or is it full Super BurnOut with render to linebuffer already? Those sprites are huge!

Yikes! There’s no need to be hostile about it. Are you working on Nitrous as well?

Edited by ColecoGamer
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...