Search the Community
Showing results for tags 'Tips & Tricks'.
Found 2 results
Kelsey (who owns two retro gaming stores in Seattle) and I share our TIPS & TRICKS for haggling at retro game stores, expos, garage sales & craigslist. Our years of game collecting AND store ownership offer a unique perspective on getting the best deal AND being respectful to the other party. TIPS: Garage sales are typically the easiest Be nice & respectful Know what is popular & what isn't Retail store prices have business expenses added Slow selling games are sometimes easier to haggle with Buy in bulk if possible Politely point out cosmetic flaws Engage seller in conversation Flaws may already be factored into the price Trading games sometimes is more valuable than cash! What did we forget? What other suggestions would you offer to other game collectors looking to perfect the art of the deal?
While Atari's Stella Programmer's Guide urges to use "2 byte fractional addition techniques", many developers back then and even today choose to base their updates (movement, animation etc.) on a counter which is updated every frame. It is easier to handle and saves RAM and ROM space. But a NTSC to PAL-50 conversion based on a frame counter will slow down by ~17%. No good! A simple solution is converting to PAL-60. This works with almost all modern TVs. However back then, this was no option. Also the extra scan lines of PAL-50 allow for extra content. And for a vice versa, PAL-50 to NTSC conversion, we have to adjust the frame rate, even today. While creating my Pitfall!x16 hack, I came up with the idea to accelerate the frame counter. Every 5th frame the counter has to be increased twice. But these updates cannot be done in any frame, e.g. in Pitfall! (like in most other cases I have seen so far), the updates happen in frames 2^n (here every 2nd, 4th, 8th and 128th frame). So when increasing the frame counter a 2nd time, we must not skip these frames! Also the additional counter updates should not be noticeable, so they must be (more or less) evenly distributed. I save you the rather complicated math and simply show you my code: .doInc inc frameCounter lda frameCounter cmp #%01010011 ; 83 (1x) beq .doInc and #%1111111 cmp #%0010011 ; 19, 147 (2x) beq .doInc and #%11111 cmp #%00011 ; 3, 35, 67... (8x) beq .doInc and #%111 cmp #%111 ; 7, 15, 23... (32x) beq .doInc This code uses no extra RAM and 24 bytes ROM. For 10 seconds (500 frames) the counter is off by just 2 (= 0.4% here, 0.33...% on average) However, there are some cases this code doesn't catch: updates which happen every frame - here you have to find individual solutions updates which don't happen at frame 2^n (e.g. every other odd frame) - maybe you can move them to frame 2^n For solving 1., one could e.g. call the same code twice (like the frame counter updates) or switch to fractional math here. For problem 2. a simple fix may do, e.g.: lda frameCounter lsr bcs .doUpdate ; replace with bcc Attached you find a speed compensated PAL-50 version of my hack. Except for minor exceptions (e.g. Harry falling and sound speed), it plays 99.66...% identical with the NTSC version. Pitfall!x16 (2017) (Activision, Thomas Jentzsch) (PAL-50).bin