| |
Released At :
The 2015 REU Compo
Achievements :
C64 Demo Competition at The 2015 REU Compo : #2
Credits :
SIDs used in this release :
Download :
Look for downloads on external sites:
Pokefinder.org
User Comment Submitted by ChristopherJam on 20 November 2018 User Comment Submitted by Jak T Rip on 8 April 2016
Very nice screen and also the music rox! Wish this would be longer. And super title screen pic. | User Comment Submitted by ChristopherJam on 9 January 2016 User Comment Submitted by Brush on 9 January 2016
@ChristopherJam Thank you for your effort. I'm honoured you acted on my feedback! Now it looks really OK. Distorted for obvious limitations related reasons but not jumpy and in some weird sense smooth :) | User Comment Submitted by ChristopherJam on 9 January 2016
Just uploaded a minor bugpatch (the 20160109 file) that fixes the jumpiness Brush referred to, and also clamps the alpha of the dropshadow to at most 66% (latter was just an art fix, no code changed).
Probably shouldn't affect your vote, as the deadline was a week ago now :P | User Comment Submitted by DKT on 2 January 2016
The screen looks just unbelievable. | User Comment Submitted by ChristopherJam on 2 January 2016
Hedning: Yup, that looks fine. Thanks for testing!
Oswald: Exactly the reaction I was looking for \o/ | User Comment Submitted by hedning on 2 January 2016
ChristopherJam: Looks good to me. Ran it on a real 512k REU, C64C. | User Comment Submitted by Oswald on 2 January 2016
crazy, its like seeing fli stuff the first time back in the days :) | User Comment Submitted by hedning on 2 January 2016
I couldn't see any bugs when run on real REU. Will test it again tomorrow. | User Comment Submitted by ChristopherJam on 1 January 2016
@Brush: Yes, I'm only updating 13 rows, and should have been able to achieve slimy. The distortion would've needed mipmapping to fix, but the jumpyness I think I've only just worked out how to fix, a day too late. Perhaps an out-of-compo Reutastic+ might be called for
@Isildur: High praise indeed, thank you! | User Comment Submitted by Isildur on 1 January 2016
Congrats Christopher. Very good production.
Looking forward to see more from you! You are one of the best C64 coders. | User Comment Submitted by Brush on 1 January 2016
I'm not sure if i'm following. If you don't have enought bandwidth, then by updating only certain percentage of the lines you should achieve a sort of "slimy" movement. Here it's kind of jumpy. I'm not sure how to describe it better but it's just weird :) | User Comment Submitted by ChristopherJam on 1 January 2016
Actually, now I think about it, I'm moving the top pixel line of the image smoothly up the screen, so when the image is squashed to half height as it first comes on, there'll be a jump every eight frames each time that line crosses a character boundary; the 7 pixels above will appear, and the 7 pixels below will be replaced with 7 pixels that lie above a line 16 pixels further down.
The maths would have been easier if I'd had enough DMA time to update 25 rows per frame, but 2/3 of the bus bandwidth goes on the treucolour image. | User Comment Submitted by ChristopherJam on 1 January 2016
Thanks!
TBH my maths might be a bit off for the effect on the left. I've got just enough raster time offscreen to DMA in 13 slices, each an 8 pixel high window into the source; only got the effect sequencer off the ground a day before the deadline and still had some art to finish, so I've not spent much time tuning it. | User Comment Submitted by Brush on 1 January 2016
Nice one! May i ask about the effect on the left? Is it my emu this time or is it a bit distorted and jumpy when it moves and it's by design? | User Comment Submitted by ChristopherJam on 1 January 2016
36x200 MCM any pixel any colour, but I need to run an offline brute force search to allocate the layers. I've no proof that it works, but I've tried a few hundred million permutations of the non-background colours with no failures.
d800 is held constant for final 10 columns (it's all the allocator can deal with/needs), so that gives us 2 bg colours per screen (d021 and d800)
Another 9 colours per line come from sprites, column coverage as follows:
Layer([0,1,2, 5,6,7,],2), $d025-6
Layer([0,1,2,3,4,5 ],3), $d027-9
Layer([ 2,3,4,5,6,7,],2), $d02a-b
Layer([0,1,2, ]), $d02c
Layer([ 5,6,7,]), $d02d
2 char colours per 4x1 (VM)
Columns -1 and 8 use the two VM colours in their first two/last two pixels respectively. | User Comment Submitted by Joe on 1 January 2016
Could you describe something of the "FLI"-mode on the right? Looks neat.. Still miss that noone did the overscans just yet for their reu-entries.. | User Comment Submitted by Digger on 1 January 2016 User Comment Submitted by Shine on 1 January 2016
Indeed ... this is really nice!!! <3 Music is so great too! ;) | User Comment Submitted by Joe on 1 January 2016
|
|
|
| Search CSDb |
| Navigate | |
|
| Detailed Info | |
|
| Fun Stuff | |
· Goofs · Hidden Parts · Trivia
|
|
| Forum | |
|
| Support CSDb | |
|
| |
|