-
Content Count
27,895 -
Joined
-
Days Won
3
Content Type
Profiles
Member Map
Forums
Blogs
Gallery
Calendar
Store
Everything posted by Thomas Jentzsch
-
After some experimenting, I think I found out how PAL palettes a generated. PAL uses YUV and here is the pseudo code for calculating U and V. for chroma = 2 to 14 idx = 15 - chroma U[idx] = sin(180 + 22.5 * chroma) if idx & 1 == 0 // even colors V[idx] = sin(180 + shift * (chroma - 3) / 2) else // odd colors V[idx] = sin(180 + shift * chroma / 2) The "shift" parameter can be manipulated by the pot, which is very sensitive and only works in a small range. And it affects only V, for U the phase shift is set fixed to 22.5° (360° / 16). A setting of 32.7° (~360° / 11) leads to colors 3 and 2 being identical (which can be reproduced on my console). 30.0° (360° / 12) seems a good default setting. Instead of (chroma - 3) -3.5 or -4 work too. Then "shift" has to be increased accordingly. Overall color C is quite close to D.
-
Do you use the latest i2c_v2.3.inc? (v2.2 created some noise on the AtariVox)
-
Bumping this because I am currently working on a new palette feature in Stella. Which is not easy without having an NTSC system. I wonder if the "hue begin point" is static at ~33° for NTSC (~57° for PAL) or if that wanders with system settings or when warming up too. Would a higher phase shift increase the begin point too?
-
With TV effects enabled, R77 will simply interpolate the vertically. Which makes the picture a bit more blurred. But that fits to TV effects.
-
A bit more information would be helpful, e.g. a save state.
-
Plaque Attack is only available on cart yet.
-
"...for faster action." Liars!
-
Comeback? They never disappeared.
-
Colony 7, Missile Control and Plague Attack seem to be missing on your list.
-
I think this is a first regarding ROM space. We have demos with larger space, but IITC no homebrew yet.
-
Have you though about further compressing your maps. I suppose both, Run-Length-Encoding and Huffman encoding would give very good results here. Problem is, that you would have to do this on-the-fly, because you have very little RAM to decode into. But maybe it is worth thinking about it, if you should run out of ROM.
-
Found this just now. I had a similar problem in "The Stacks". However my solution is different. I am only keeping track of each item (found or not). So that's one bit per item which can be collected. Or in your case, each chest which can be looted. I don't know how many chest can there be in your game, but I suppose the number is rather low. Now, how do I know which item belongs to which bit? By sequencing them. Each item has a fixed position in the sequence of items and therefore directly maps to the sequence of bits which track its state. Could you do something similar with the chests?
-
Thanks. And it was quite some work, especially @DirtyHairy invested a lot of brain and labor into the scaling algorithm. Which then affected R77 performance and required some extra measures.
-
I know this too well. But I usually decide to do what is most fun for me now (except when something must to be done now). This keeps the motivation alive.
-
What you see is the result of an improvement in emulation. With this change, Stella is now emulating correct pixel sizes. And these are not square like a digital display's pixel. Also their height is influenced by the number of scanlines created by the ROM. Previously the height of a pixel was fixed and its width was changed depending on the user's aspect ratio setting. Also there was no correct rounding of this width (if you count the width of a vertical line in your 6.0.2 screenshot you will notice the error, it will become even visually obvious at low zoom, see attachment). This lead to varying window sizes (also PAL was much larger than NTSC). But this is not how a CRT behaves. There the width of a pixel is fixed, and the height changes between NTSC and PAL. So we switched from interpolated pixel width to interpolated pixel height. And we are now correctly interpolating.
-
That's possible now too. You just have to release the joystick directions and press fire before moving again.
-
What you describe is what we have now. Not sure what could be switched here. Most likely not. That would require too many bytes.
-
16:9 is only used in the launcher for the Stella settings, not during emulation. Can you please double check?
-
Update: With help from OmegaMatrix (thanks a lot!) I found the necessary 15 bytes for making PAL-60 stable too (RC8 added to first post). Unless someone finds a bug, I consider this done. Many thanks to everyone for your support!
