Jump to content
IGNORED

Down the rabbit hole. Here we go


phoenixdownita

Recommended Posts

  • 2 weeks later...

As mentioned last time, I was out of state last weekend, so this weekend was the first (since last time I worked on this), that I got some time to continue working on this.

 

- I found out why the strafing of the road did not really work 2 weeks ago and was glitching - it was a HW bug, not code bug. Feature that is supposed to work according to jag docs, but does not, really. Took me over a day to come up with two additional algorithms to address that bug, but it is what it is.

- I reworked the road perspective, so there is now much higher / better sense of perspective into the distance (though, far from ideal, of course)

- I implemented a speed-up / speed-down

 

- Since last time the total effort was 3.5 days, and I did about 1.5 days since last time (far from whole weekend, but some progress nonetheless), the current running total is 5 days.

- There are two new glitches - as many will certainly be pleased to hear. The HW workaround algorithm is only 80% finished, so there are glitches at the screen edge. I masked the big one on the right with huge black triangle, and there is a little one on the left (unmasked).

 

PlaysWithWolves just got a build. It's 10pm, so not sure if he can still record a video or not (probably tomorrow at worst).

 

As for next progress:

- I will be out of state most of next week, including the weekend

- The soonest I can get to RR is exactly 2 weeks from now (the weekend)

 

 

  • Like 2
Link to comment
Share on other sites

Hey, progress is progress, no matter how little. I am just happy the project is alive, hehe.

Thanks, I do not plan to switch back to H.E.R.O. just yet. I want to see it interactive and playable, and at least some portions of the renderer on GPU.

While it's true that RR does not really help with performance of HERO renderer directly, there is some experience leakage. I learnt actually a lot of new stuff about texturing on jag. There are just so many ways how to achieve the same end effect, it just takes a lot of experimenting to see what works and what doesn't.

 

There are few new things and tricks I'd really like to try on HERO that I learnt on RR, but that's going to have to wait.

 

Looks like 5 days of work are realistic to achieve in about 1 calendar month.

 

Here's hoping the next 5 days of work bring:

- curves

- hills

- fixed texturing (for clipped buildings at the edge)

- no more HW bugs, please :)

  • Like 4
Link to comment
Share on other sites

Yeah that guy is 15 feet tall, or it's a little peoples' town.

 

Easy to fix?

In this particular case, yes. I just need to resize the biker bitmap and reimport it into the engine. Which is, like 5-minute thing.

 

I could, of course use the run-time scaling, but why waste performance and memory for an offline fix.

 

 

 

However, after rescaling, the biker will be much smaller on screen.

 

So, the ideal fix would be to adjust the coordinate systems and matrices for both the road and buildings (so that the biker bitmap can stay untouched).

Link to comment
Share on other sites

Thanks, I do not plan to switch back to H.E.R.O. just yet. I want to see it interactive and playable, and at least some portions of the renderer on GPU.

While it's true that RR does not really help with performance of HERO renderer directly, there is some experience leakage. I learnt actually a lot of new stuff about texturing on jag. There are just so many ways how to achieve the same end effect, it just takes a lot of experimenting to see what works and what doesn't.

 

There are few new things and tricks I'd really like to try on HERO that I learnt on RR, but that's going to have to wait.

 

Looks like 5 days of work are realistic to achieve in about 1 calendar month.

 

Here's hoping the next 5 days of work bring:

- curves

- hills

- fixed texturing (for clipped buildings at the edge)

- no more HW bugs, please :)

5 days of work in a calendar month is a lot of time to devote to a hobby project! I am hoping in the new year, I can get back that amount of time for working on my car.

 

Care to disclose the H/W bug? Also, did it show up in the emulated code, or did it only show when running on real hardware? I am just curious as to how the accuracy of Jag emulators is these days. I am a lifelong Atari 8-bit (computer) user, and the newest emulator, Altirra, is still being updated weekly, as more non cycle perfect cases are being found.

 

This is why as cool as emulation is, I hope to always have the real hardware as well.

Link to comment
Share on other sites

you may want to look into the buildings as they move off the screen, i'm pretty sure buildings do not stretch :P

It'll be because when the co-ordinates are checked for display they are outside the screen area and so it uses the current Y value of the block instead of the calculated one - you'll notice that it seems to be working okay until it crosses the boundary when it suddenly jumps back to the same height as the right hand side of the block. On the LHS the X location is also capped at 0 (similar on the RHS) which causes the building textures to shrink as the widths will be wrong.

Link to comment
Share on other sites

It'll be because when the co-ordinates are checked for display they are outside the screen area and so it uses the current Y value of the block instead of the calculated one

Uhm, no. Like, at all :)

I have the calculated clipped values from the very beginning. The original problem is caused by the Blitter, as it refuses to zoom the span appropriately after a certain threshold. At this point, it is inconclusive (50/50), whether it's a HW bug, or incorrect usage. But even the docs say that clipping is buggy.

 

you'll notice that it seems to be working okay until it crosses the boundary when it suddenly jumps back to the same height as the right hand side of the block

Uhm, no. It's actually happening even slightly before the boundary (it's dependent on transformation, thus depends directly on height of the building). Looks like I tweaked the values well, if noone noticed that ;-)

The reason it aligns to the same Y value is that previously the buildings gave an impression of falling off. This looks different now.

 

On the LHS the X location is also capped at 0 (similar on the RHS) which causes the building textures to shrink as the widths will be wrong.

That is just a quick hack to avoid the excessive texel zoom that is a result of the current projection. Projection needs to be adjusted for multiple reasons anyway, so this will get addressed once projection does..

 

 

Overall, I need to experiment with Blitter a bit more to see if what I want is actually even possible on jag. I have the reference rasterizer working anyway, so I can always switch to that, but I'd like to do it the jag way :-D

Link to comment
Share on other sites

Uhm, no. Like, at all :)

I have the calculated clipped values from the very beginning. The original problem is caused by the Blitter, as it refuses to zoom the span appropriately after a certain threshold. At this point, it is inconclusive (50/50), whether it's a HW bug, or incorrect usage. But even the docs say that clipping is buggy.

 

Uhm, no. It's actually happening even slightly before the boundary (it's dependent on transformation, thus depends directly on height of the building). Looks like I tweaked the values well, if noone noticed that ;-)

The reason it aligns to the same Y value is that previously the buildings gave an impression of falling off. This looks different now.

 

That is just a quick hack to avoid the excessive texel zoom that is a result of the current projection. Projection needs to be adjusted for multiple reasons anyway, so this will get addressed once projection does..

 

 

Overall, I need to experiment with Blitter a bit more to see if what I want is actually even possible on jag. I have the reference rasterizer working anyway, so I can always switch to that, but I'd like to do it the jag way :-D

 

I wasn't going to reply to this but honestly....

 

In para 1 you say you use the calculated values and that it's probably a blitter error or maybe your interaction with it - it's gone from the H/W error in your earlier update to maybe I don't know what I'm doing in one line.

 

In para 2 you say it doesn't change at the boundary, then explain that it does change near the boundary but that boundary depends on the height of the object. You also say you do change the Y value, which is what you said you didn't do in para 1

 

In para 3 you agree with me that you are changing the X value too as a 'quick fix' as there is an underlying projection issue that needs correcting. As it currently displays as "Leather dude in the land of the melting rubber buildings" you might want to correct that first. You have now potentially changed both co-ordinates.

 

BTW you also still haven't shown anything running on real hardware.

 

I'm out of this thread

  • Like 2
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...