15 July 2024, 21:44 | #4621 |
Registered User
Join Date: Oct 2020
Location: Bicester
Posts: 2,066
|
I get sound breakup no matter what due to the age of the PC I am running.
the difference could be due to forcing RTG to run a 50hz (fake VBL) to keep timing simple regardless of actual refresh rate? |
15 July 2024, 21:46 | #4622 | |
Registered User
Join Date: Oct 2020
Location: Bicester
Posts: 2,066
|
Quote:
|
|
15 July 2024, 22:10 | #4623 |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,716
|
Not sure. It's definitely not just audio, I get jittery screen updates. It's much more fluid in AGA
|
15 July 2024, 22:11 | #4624 |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,716
|
|
15 July 2024, 23:16 | #4625 |
Registered User
Join Date: Oct 2020
Location: Bicester
Posts: 2,066
|
|
16 July 2024, 10:09 | #4626 |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,716
|
|
16 July 2024, 18:47 | #4627 | |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,279
|
Quote:
I don't think I'd bother trying to reschedule the instructions in a loop like this, better to just do general optimizations like the one you mentioned. It's only like 100-ish cycles per iteration (ignoring cache effects etc.) and is probably not really a hot-hot spot. Many of the instructions a pOEP-only (muls/swap) so they can't pair anyway. Much too great a risk of breaking the code for extremely marginal gains. Running my simple, automated cycle counter on the loop I'd say that it's probably not as bad as you think, and there are already quite a bit of instructions that will end up in the sOEP. |
|
16 July 2024, 18:51 | #4628 |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,716
|
I did reorder a tiny bit, there shouldn't be (m)any successive pOEP instructions, but removing register dependencies wasn't really possible.
Out of interest, what does your counter say when we replace the muls #85 and slightly later asr.l #8 with divs #3 ? |
16 July 2024, 19:12 | #4629 | |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,279
|
Quote:
You can try it yourself: https://github.com/mras0/acycles It works OK for simple innerloops (like a texture mapping one or your sound mixing stuff) and straight-line instruction sequences, but everything else is likely wildly incorrect. I use it to flesh out ideas for instruction scheduling, and then verify on real HW. #include <stddisclaimer.h> |
|
16 July 2024, 19:18 | #4630 |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,716
|
I had to get rid of it though. At one point, I here were scenes switch literally thousands of divisions (and long divisions) per frame
|
24 July 2024, 19:10 | #4631 |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,716
|
In a rare moment of free time, I want to work on the engine.
I have an outstanding optimisation task to do with overdraw (in this case, drawing the sky where it is potentially needed but in practise is not, based on level errata data). This needs a buffer that I prefer to be an allocate once affair, rather than every time a level is loaded as it has a dependency on the zone count. Now, it turns out that the zone count isn't really strongly limited anywhere in the engine (there may be some assumptions of 256 in places) and I know that @abu_the_monkey has experimented with a level editor supporting more than that many zones. For my use case, the data is a bitmap and it doesn't make sense to dynamically allocate it every time. So what I want to do is to define a hard upper limit on the zone count. Somethinhg that goes into defs.i and defs.h and can be revised by software updates only. The question is what is a good hard upper limit? I was thinking maybe 512 for now? |
24 July 2024, 21:53 | #4632 |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,716
|
I have the sky backdrop errata mechanism working.
In devmode, you can use X to toggle the sky visibility for the current zone (note, you can only disable it if the zone has sky according to the level data, otherwise it does nothing). Pressing Z clears all the override data and pressing V causes it to be dumped to the RAM disk (this happens at the point where the developer overlay information is drawn, doing it immediately is not possible as we are in an interrupt). For now, copying the dumped file to Game/Levels/LEVEL_X/properties.dat causes the game to treat it as the per-level properties file (it will form the first section of it anyway) and reloads the data and uses it. I've tested with Arena level of my mod which has a significant amount of sky overdraw in the beginning area and it works. There is still the odd 1-frame glitch passing between zones that are overridden to not show it. Unsurprisingly, this saves a lot of cycles in areas where the sky is improperly tagged for rendering by the level data. |
24 July 2024, 22:09 | #4633 | ||
Registered User
Join Date: Oct 2020
Location: Bicester
Posts: 2,066
|
Quote:
Quote:
|
||
24 July 2024, 22:17 | #4634 |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,716
|
Just added another test with level G which had the same basic issue in a couple of places.
This is just the start - I intend to add per zone "force cull" to work around cases where the editor is too conservative with zone visibility data. Who cares if a pixel of one zone are visible from a very specific location in another that you can't stand still on for more than a frame? Better to cull it and risk a single pixel / single frame disturbance and avoid rendering an entire zone to overdraw all but that pixel. It's all pushed to the misc/redesign branch of my mod. The files are just 64 bytes at the moment because the data is a bit per zone (up to 512 of them). When zone culling lists get added, they will be varying length and will need a header. |
24 July 2024, 23:51 | #4635 |
Registered User
Join Date: Oct 2020
Location: Bicester
Posts: 2,066
|
@Karlos
I am away on holiday at the mo, but will be sure to check it out when I return. |
25 July 2024, 09:28 | #4636 | |
Registered User
Join Date: Jun 2015
Location: Germany
Posts: 1,938
|
Quote:
Similarly it is probably too complicated to turn the sky into a special type of ceilings that are texture-mapped without any perspective correction but straight from the sky-graphics. |
|
25 July 2024, 11:50 | #4637 | |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,716
|
Quote:
I think the editor just has limitations on its abilities. For one, I don't think it takes vertical separation into consideration at all. A scenario: Imagine two connected zones, A and B. A is a deep pit with an open sky, B is a cave at the bottom. A is tagged as having visible sky and if you have a jetpack you can fly to a vantage where it will be rendered. Zone B will be tagged as having "potentially visible sky" since it has an open connection to A, and therefore the sky of zone A is potentially visible. However, the sky can literally never be seen from B in practise. because A's ceiling is never visible from B It gets worse when you add zone C to B and there's a line of sight from C to A through B. C will now also be tagged as having potentially visible sky. So you are 100% correct that a special ceiling renderer that puts the sky texture in at the right offset a better way. However, the data layout and render just aren't quite ready for it. For now, this is a "better than nothing" solution but it's not pointless - it introduces the mechanism for loading a bunch of level specific ad-hoc data that I want to add. Even with a "sky ceiling" solution, there are still problems since we get overdraw between zones sometimes that a mechanism like this can be used to limit, e.g. "due to differences in verticality, exclude zones A, B and C from the PVS of Zone X". |
|
25 July 2024, 12:30 | #4638 |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,716
|
Below is a good example of how bad it gets sometimes. This is the beginning of Level H.
The darker blue areas are the zones in which the sky is directly visible, either because the zone is open sky or directly shares an edge with an open sky zone at a similar height (I may have missed a couple but you get the idea). The lighter blue areas are the zones in which the sky is legitimately potentially visible. The large octagonal region is a bit of a shame and should be restructured since the sky is only actually visible from the right hand end of it. However, bisecting that zone accordingly has created more PVS pain than I care to revisit. The pinkish red areas are all the zones the editor has decided the sky can potentially be visible from when in practise there are no viable line of sight paths. I can now tag these in game and dump the data when I am happy, from the dev build. |
25 July 2024, 21:44 | #4639 |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,716
|
I managed to remove the last of the old messages code (the bottom of screen stuff) that was referenced from a few places.
This was just a lucky find as I was wanting to work out what happens when the game is paused, so that we can display some stuff. It turns out the pause is a pretty brutal hard polling loop in the main render path. This is a bit annoying. It would be a lot better if it let the system breathe a bit. |
Currently Active Users Viewing This Thread: 5 (0 members and 5 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Alien Breed 3D II The Killing Grounds RTG patch | Angus | Retrogaming General Discussion | 63 | 14 December 2022 15:20 |
Alien Breed & Alien Breed '92: SE - delay when picking up items / opening doors | Ian | support.WinUAE | 16 | 23 December 2016 15:50 |
Alien Breed 3D II : The Killing Grounds code booklet | alexh | support.Games | 19 | 10 October 2012 22:17 |
Alien Breed 3D 2 - The Killing Grounds | Ironclaw | support.Games | 12 | 13 September 2005 13:07 |
HD Version of Alien Breed I ? | Kintaro | request.Old Rare Games | 20 | 31 July 2003 10:48 |
|
|