- Welcome to CPCWiki forum.
The ultimate Amstrad CPC community!
News:
Printed Amstrad Addict magazine announced, check it out here!
Recent posts
#11
Quote from: Deevee on Today at 16:32Quote from: SerErris on Today at 10:23I would still do it line by line.
Start from the hsync singnal and scan to the next hsync, then output it twice to the target monitor with double pixel frequency.
That would catch everything the CPC will do, regardless of video modes or anything else.
If you just do that this needs only one line of memory and is never wrong, whatever the demo might do and it is also very fast (no additional delay) in the output. So even any mode switch will be done immediately without any adaption time.
I might be wrong, but I think some demos force multiple hsyncs per line, to allow multiple modes in a line.
Oh wow! That will be a cool use case to handle. So far my logic is like: wait for hsync to go up, then to go down, then read the line in a loop with constant number of pixels (assuming mode 2, in other case it just reads one pixel multiple time). I will have to change it completely to handle something like that. I can't wait to have it working with basic use cases and start working on cases like that one
#12
Quote from: SerErris on Today at 10:23I would still do it line by line.
Start from the hsync singnal and scan to the next hsync, then output it twice to the target monitor with double pixel frequency.
That would catch everything the CPC will do, regardless of video modes or anything else.
If you just do that this needs only one line of memory and is never wrong, whatever the demo might do and it is also very fast (no additional delay) in the output. So even any mode switch will be done immediately without any adaption time.
I might be wrong, but I think some demos force multiple hsyncs per line, to allow multiple modes in a line.
#13
There is already an almost complete and almost transparent Z80 emulation in Orgasm, and I plan to emulate the CRTC soon too.
UI-wise, the registers wouldn't be displayed unconditionally, because there is no much room and it would make the trace slower.
There are already two visualization modes in the trace debugging screen that you can switch with CTRL-V: memory dump or source visualization.
I plan to enable the CRTC visualization with another shortcut, CTRL-SHIFT-V. There is this UI rationale, but also a practical reason ; to emulate the CRTC, one must know the register setup. One way would be to trace from the start of the execution, but it might be too slow.
What I am proposing instead is... when you press CTRL-SHIFT-V, it would fast-trace while tracking CRTC state, until the next break.
UI-wise, the registers wouldn't be displayed unconditionally, because there is no much room and it would make the trace slower.
There are already two visualization modes in the trace debugging screen that you can switch with CTRL-V: memory dump or source visualization.
I plan to enable the CRTC visualization with another shortcut, CTRL-SHIFT-V. There is this UI rationale, but also a practical reason ; to emulate the CRTC, one must know the register setup. One way would be to trace from the start of the execution, but it might be too slow.
What I am proposing instead is... when you press CTRL-SHIFT-V, it would fast-trace while tracking CRTC state, until the next break.
#14
Quote from: SerErris on Today at 10:23I would still do it line by line.To be honest that is what I wanted to do first. This way there is for sure no issues with ram or with tearing that could happen when frame in RAM is being displayed and overwritten in the same moment, but there are two main issues I found. First is timing. When reading Amstrad video, it has to be extremely accurate. For VGA output it also has to be quite accurate. That leaves not much space for any extra operations like doubling the line etc. and keeping everything in sync at the same time. Still maybe this potentially could be made at some point.
Start from the hsync singnal and scan to the next hsync, then output it twice to the target monitor with double pixel frequency.
That would catch everything the CPC will do, regardless of video modes or anything else.
If you just do that this needs only one line of memory and is never wrong, whatever the demo might do and it is also very fast (no additional delay) in the output. So even any mode switch will be done immediately without any adaption time.
Other issue is related to possible resolutions and frame rates. In your solution we have to keep the same vertical frequency/frame rate on output as on input. Looking at available frequencies for monitors, like my main one: http://dlcdnet.asus.com/pub/ASUS/LCD%20Monitors/PB277/ASUS_PB277Q_English.pdf the options for available resolutions with 50hz fps is quite limited. When I checked some old TV I have, it was even more limited. Some monitors have so huge tolerance that even when not officially supporting 50hz they would probabaly handle it. Still I don't want to end up with something that works only on a fraction of monitors. When we add requirement about resolution it will be even harder. Actually my only option is 800x600 (or something close) to be able to fit the whole amstrad screen and still be able to send pixels quick enough. That gives even smaller number of possible frame rates.
On the other hand when I think about pros and cons of keeping the whole frame in memory, then first of all it just works and so far I don't see tearing. It could also open the possibilities to do any postprocessing of a frame. In future, I could e.g. handle some special cases, like mentioned earlier smooth scrolling or even try to simulate dithering, getting closer to what can be seen on original monitor rather than on typical scandoubler. All that stuff would be harder having access to one line only.
... and some good news - I managed to work around the limitation of number of lines being the power of 2. So now I have the totally full Amstrad screen displayed, even with a bit of those black lines just after vsync signal. Any overscan should not be a problem. This weekend I plan to finish the electronics part, and then I will follow with more detailed testing to know better what works and what doesn't.
#15
Ok, its not really a bug a bug in the sense it can happend playing the game in a normal way, its a bug made for poke the game.
I mean.
The array between &4e34/-&4e74 Its a array of 65 items of the game.
Each item have five parameters.
1=unkown.
2=draw h/v item in the screen
3=draw h/v item in the screen.
4=if you have picked up it or you don't and its ready on the floor to pickup it
5=type of item
So this can store any item really.
So you begin with five dinamites in your inventory
1.iX=4f5b
2.ix=4f60
3.ix=4f65
4.ix=4f6a
5.ix=4f6f
When you pickup a dinamite from the floor then the first free slot of the &4e34 array its add with the dinamite you have picked up.
So if i pickup the dinamite in the first room we have now.
0.iX=3437
1.iX=4f5b
2.ix=4f60
3.ix=4f65
4.ix=4f6a
5.ix=4f6f
now, when you drop a dinamite the subrutine of &644c walk thought the array &4e34 looking to find the first dinamite he found, to modify it and return it to free slot.
As a entry in the array is add every time you pickup one dinamite and one is deleted when you drop one, it imposible it crash, because when you rearch 00 in &53DD &64cc refused modify anything and he just exit the subrutine.
But if you made a poke in &53DD,Then he have five dinamites in the &4e34, And &53DD its >5.
So you drop the five dinamites,but &64cc don't refuse modifiy the next dinamite because &53DD >0. So he go out the range between
&4e34/-&4e74, so he began modify another parts of the code every time you drop a dynamite more and more far in to the code from &4e34,Destroying finally the logic of the game and crashing it.
I mean.
The array between &4e34/-&4e74 Its a array of 65 items of the game.
Each item have five parameters.
1=unkown.
2=draw h/v item in the screen
3=draw h/v item in the screen.
4=if you have picked up it or you don't and its ready on the floor to pickup it
5=type of item
So this can store any item really.
So you begin with five dinamites in your inventory
1.iX=4f5b
2.ix=4f60
3.ix=4f65
4.ix=4f6a
5.ix=4f6f
When you pickup a dinamite from the floor then the first free slot of the &4e34 array its add with the dinamite you have picked up.
So if i pickup the dinamite in the first room we have now.
0.iX=3437
1.iX=4f5b
2.ix=4f60
3.ix=4f65
4.ix=4f6a
5.ix=4f6f
now, when you drop a dinamite the subrutine of &644c walk thought the array &4e34 looking to find the first dinamite he found, to modify it and return it to free slot.
As a entry in the array is add every time you pickup one dinamite and one is deleted when you drop one, it imposible it crash, because when you rearch 00 in &53DD &64cc refused modify anything and he just exit the subrutine.
But if you made a poke in &53DD,Then he have five dinamites in the &4e34, And &53DD its >5.
So you drop the five dinamites,but &64cc don't refuse modifiy the next dinamite because &53DD >0. So he go out the range between
&4e34/-&4e74, so he began modify another parts of the code every time you drop a dynamite more and more far in to the code from &4e34,Destroying finally the logic of the game and crashing it.
#16
Looks like I am wrong, v1.4 is not the last release of this game because I found some more bugs to fix.
v1.5 Change Log (Build 640)
The updated binaries and source code can be found here if your interested:
https://awergh.itch.io/fitzroy-feels-the-heat/devlog/721198/fitzroy-feels-the-heat-v15
Thanks to @Nesu for pointing out how to reproduce my teleporter bug.
Sometimes when you are stuck another set of eyes is really helpful for figuring out why things aren't working right.
This bug manifests when you are using the last teleporter in the teleporter level where instead of taking you to the exit it takes you back to the start of the level, this is both confusing and annoying.
As it turned out it could only happen in very specific circumstances found in the teleporter map.
This bug is a side effect of how I activate interactables.
When a player attempts to activate an interactable (teleporter in this case) the game will attempt to activate any interactable in the cells that the player is currently occupying (1 of 4 cells in the grid).
This normally is not a problem but once the player has teleported the game tries to activate an interactable in a different room to the one they were before they teleported.
Below is a partial display of the level (from the map editor) with links visible (the links are used to connect teleporters together).
If you (the player) are entirely on the teleporter on activation (orange circle right side) it will take you to the teleporter at the end of the link (orange circle left side) as expected.
If you are overlapping the red circle (right side) it will first move you to the room on the left (as expected), then it will attempt to activate an interactable in the cell below the first teleporter (red circle right room).
But as the player has moved to the left room it will instead activate the teleporter at the the red circle (left room).
This teleports the player to the wrong location (pink circle left room).
You cannot view this attachment.
The fix was not complicated, simply adding a check that the player has not recently changed rooms (teleported) which prevents this situation from happening
I have finished the game in a single sitting but I also died during the attempt so I am still working on this (probably).
This was part of what caused me to hold off updating for a while but I figure now is a good time and I haven't seen any bugs this month so its probably safe to do so.
v1.5 Change Log (Build 640)
- Always change minimum and maximum temperature by the same amount during adjustment (by the temperature system).
- Stop all game timers after finishing a level to prevent any timers affecting the game after finishing a level.
- Do not continue activating interactables in the cells that the player was previously activating after teleporting (teleporter level final teleporter bug).
The updated binaries and source code can be found here if your interested:
https://awergh.itch.io/fitzroy-feels-the-heat/devlog/721198/fitzroy-feels-the-heat-v15
Thanks to @Nesu for pointing out how to reproduce my teleporter bug.
Sometimes when you are stuck another set of eyes is really helpful for figuring out why things aren't working right.
This bug manifests when you are using the last teleporter in the teleporter level where instead of taking you to the exit it takes you back to the start of the level, this is both confusing and annoying.
As it turned out it could only happen in very specific circumstances found in the teleporter map.
This bug is a side effect of how I activate interactables.
When a player attempts to activate an interactable (teleporter in this case) the game will attempt to activate any interactable in the cells that the player is currently occupying (1 of 4 cells in the grid).
This normally is not a problem but once the player has teleported the game tries to activate an interactable in a different room to the one they were before they teleported.
Below is a partial display of the level (from the map editor) with links visible (the links are used to connect teleporters together).
If you (the player) are entirely on the teleporter on activation (orange circle right side) it will take you to the teleporter at the end of the link (orange circle left side) as expected.
If you are overlapping the red circle (right side) it will first move you to the room on the left (as expected), then it will attempt to activate an interactable in the cell below the first teleporter (red circle right room).
But as the player has moved to the left room it will instead activate the teleporter at the the red circle (left room).
This teleports the player to the wrong location (pink circle left room).
You cannot view this attachment.
The fix was not complicated, simply adding a check that the player has not recently changed rooms (teleported) which prevents this situation from happening
Code Select
if (occupiedYTileTop != occupiedYTileBottom && !roomChange)
{
interactableActivated += activateInteractable(occupiedXTileLeft, occupiedYTileBottom, currentRoomX, currentRoomY, 0);
}
if (occupiedXTileLeft != occupiedXTileRight && !roomChange)
{
interactableActivated += activateInteractable(occupiedXTileRight, occupiedYTileTop, currentRoomX, currentRoomY, 0);
if (occupiedYTileTop != occupiedYTileBottom && !roomChange)
{
interactableActivated += activateInteractable(occupiedXTileRight, occupiedYTileBottom, currentRoomX, currentRoomY, 0);
}
}I have finished the game in a single sitting but I also died during the attempt so I am still working on this (probably).
This was part of what caused me to hold off updating for a while but I figure now is a good time and I haven't seen any bugs this month so its probably safe to do so.
#17
Would be nice to know if this will work! Good luck!
#18
I would still do it line by line.
Start from the hsync singnal and scan to the next hsync, then output it twice to the target monitor with double pixel frequency.
That would catch everything the CPC will do, regardless of video modes or anything else.
If you just do that this needs only one line of memory and is never wrong, whatever the demo might do and it is also very fast (no additional delay) in the output. So even any mode switch will be done immediately without any adaption time.
Start from the hsync singnal and scan to the next hsync, then output it twice to the target monitor with double pixel frequency.
That would catch everything the CPC will do, regardless of video modes or anything else.
If you just do that this needs only one line of memory and is never wrong, whatever the demo might do and it is also very fast (no additional delay) in the output. So even any mode switch will be done immediately without any adaption time.
#19
Hello guys!
During the last few days there has been an influx of new users, above the normal levels. Some of the accounts created were definitely spammer accounts, for others I have my doubts. Just wanted to ask you to report any suspicious behavior you see and it'll be taken care of.
Thanks!
During the last few days there has been an influx of new users, above the normal levels. Some of the accounts created were definitely spammer accounts, for others I have my doubts. Just wanted to ask you to report any suspicious behavior you see and it'll be taken care of.
Thanks!
#20
it's always possible (like Prehistorik II or Super Cauldron) to have some parts @50Hz and some animations @5Hz 
and it's also possible to have a dedicated engine to manage any framerate for any animation in the screen (some @50Hz, some @25Hz, ...)
even better, an automatic distribution, with priorities for main character and lower priority for background, as you must know time consumption for each element
and it's also possible to have a dedicated engine to manage any framerate for any animation in the screen (some @50Hz, some @25Hz, ...)
even better, an automatic distribution, with priorities for main character and lower priority for background, as you must know time consumption for each element