- Welcome to CPCWiki forum.
The ultimate Amstrad CPC community!
News:
Printed Amstrad Addict magazine announced, check it out here!
Recent posts
#1
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.
#2
Would be nice to know if this will work! Good luck! 
#3
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.
#4
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!
#5
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
#6
Well, it depends what your priorities are. The GX is a console after all, and 50fps gives you that arcade/console feel. It's a worthy if restrictive ambition even for the stock CPC, and the GX is plenty capable of doing what the Commodore 64 can do, so I'd definitely shoot for that. I did say a sprite game, so something equivalent to what you might see on the NES or Master System.
I know it cuts your drawing time in half but hopefully you don't need to spend all that time masking and drawing and erasing sprites either, and it's the difference between smooth arcade feel and slightly juddery home computer feel.
The CPC endured such rough FPS back in the day, it always feels really pleasing to see it hitting a clean 50.
I know it cuts your drawing time in half but hopefully you don't need to spend all that time masking and drawing and erasing sprites either, and it's the difference between smooth arcade feel and slightly juddery home computer feel.
The CPC endured such rough FPS back in the day, it always feels really pleasing to see it hitting a clean 50.
#7
Very few Amiga games are 50FPS even with all the hardware, games are normally 25FPS so I don't know why GX games should be 50FPS.
You can only move around X amount of screen data at 50FPS, at 25FPS you can double it.
You can only move around X amount of screen data at 50FPS, at 25FPS you can double it.
#8
Quote from: Anthony Flack on Yesterday at 22:39Any kind of screen buffering on the GX is also complicated by the hardware sprites, which will have to have their data buffered as well, or else they'll get ahead of everything. But a sprite game on the GX should rightly be aiming to hit 50fps anyway.Depends what you're doing, if you were aiming for something 3D like Castle Master you might not have many sprites (or just use it for things like a cursor that just needs positioning). And that's where triple buffering is most likely to be useful. It'd be fascinating to see what a Mode 0 GX Freescape would be like, especially given how much cart space you could dedicate to massive look up tables to speed up the maths...
If you're doing something sprite heavy and scrolling, you'd be more likely to lean on the hardware features and avoid even double buffering entirely (at most keeping a secondary clean background buffer).
#9
Any kind of screen buffering on the GX is also complicated by the hardware sprites, which will have to have their data buffered as well, or else they'll get ahead of everything. But a sprite game on the GX should rightly be aiming to hit 50fps anyway.
#10
Quote from: sigh on Yesterday at 18:35Sorry - I think I may have muddled up everything by not explaining well. I meant that you can fit more sprites in mode 1.
For instance - if I were to draw a sprite that is 16*16, I would be able to fit more on the mode 1 sheet.
Well there are half as many pixels across in Mode 0, so you can fit less 16*16 Mode 0 sprites compared to 16*16 Mode 1 sprites. But 16 Mode 0 pixels cover the same physical area as 32 Mode 1 pixels so it's not really a like for like comparison.
Ultimately there is absolutely no advantage to using Mode 1 over Mode 0 in terms of the number of sprites you'll get in a game. The only reasons to choose it are because you need the higher resolution for aesthetic or functional reasons (f.e. you have a lot of text) or because you have art designed for another system with square pixels (typically the Speccy but not necessarily) and don't want to spend time/effort/money reworking it.