|
| |
|
Ultiverzum [ultimate] [2023] |
AKA :
Ultimate 64
Released At :
Function 2023
Achievements :
WiLD Demo Competition at Function 2023 : #1
Credits :
SIDs used in this release :
Download :
Look for downloads on external sites:
Pokefinder.org
Summary
Submitted by Scorpy on 12 September 2023
Technical details
3d wireframe objects
---------------------
This part based on codebase64 and C= Hacking articles. Rotation matrix still 8 bit, but other computations are on 16bit. Bigger object vibrates and pulsates, looks very ugly. At the size used, this is not yet so disturbing, but it is already noticeable. Drawing polygons is not very optimized, it draw every edge, and it means most of the lines drawn twice.
Dot morph
----------
Calculations are performed using 16- and 24-bit fixed-point arithmetic. Nothing special.
Gears
-----
This is the most funniest part of coding whole demo. In the beginning of this project I wrote down which effects and algorithms want to use in this demo. Drawing something with plotter, lines, circles, polygons, EOR filler, 3D, something bitmap effects, like rotation, water, fire, etc... Line routine came from Codebase64. I just improved Hein's algorithm to draw lines for EOR filler. I calculated, drawn and think a lot how to do it perfectly. Poligons sometimes had vertical lines because lines had holes randomly. At the end I asked Amiga coders on facebook, how to fix it. It should be simple as a wood wedge, what is the trick? So finally I got the very simple answer and finished this milestone. To test polygon filler I drawn triangles, rectangles and a common routine which can draw regular polygon with 3,4,5...12 vertices. And I made a simple gear, using only sine data. You know sin(fi+d)+sin(fi-d) produces another sine wave and its amplitude depends on value d. And build up that gear structure. I had a great idea to create an animation for palnetary gear (or epicyclic gear). I planned and calculated things to do it. For this part I used exact sine data for all radius, so it produces nicer gears. I had some problems about rotations. Nothing worked as I expected. I started to read wiki, another calculations and still not worked. I downloaded mechanical books on this subject. All thing was clear but I didn't understand why doesn't work. Then I said I stop this, if nothing works I create a big table which describe which element how to rotate and where to move. After the table I realized the values are similar what I calculated before. I rewrote whole calculations from scratch and WOW it works! It do what I expected... but what was the problem with the first algorithm? I think I never know it. So this part also calculates, no precalculated shit used. (This thing stole 2-3 weeks from me.)
Plotter
--------
This is the first and almost last part in my timeline. Simple double sine dots, not quite optimized, but looks great at 48MHz. Simple and finished quickly. At last week before the party I realized there is no greetings part. I added to this plotter. Greetings images simple .BMP files, and copied line by line to the screen. Very simple too, added some calculations to "rotate" the plane. All greeting images loaded between to plotter part.
Rotozoomer
----------
Classical rotozoomer on a bitmap + sprite overlay. Resolution 96x200 in 7 colors. Why need 48 MHz on C64 while on PC it works at 12MHz full screen? On PC video memory layout is linear and 1 byte 1 pixel. Very simple to addressing and draw a dot. On C64 I should mandle 4 pixels in one byte and another 4 pixels in another byte. (Bitmap + sprite) To speed up I calculated colours of 4 pixels and stored them in zeropage. Then I used them to indexing color tables. Four pixels needs four tables of color tables (and other four tables for sprites). Then used simple LDX, LDA and LDX, ORA to convert to bitmap and sprites. These tables also do the dithering. Sprite and bitmap color tables are similar just shifted so no need them twice, they are overlapped.
Water
-----
Calculating wave movements need some CPU power and memory. I cheated this part on this. Wave map is 128x64, and used twice, and at the and the image is 128x128.
IFS fractal morph
-----------------
This is my favourite part. I started on a simple Fern fractal then a made another one. After then I read more and more articles to digging deeper into IFS fractals and I made it in a common algorithm. From this point it was clear this part needs a morph too. IFS parameters morphing and the result is very impressing. Every 3rd frame, so 17 frames/second. Using 16 bit fixed point arithmetic.
Distorted rotozoomer
--------------------
Modified rotozoomer from the beginning (it draw for bitmap only and has no dithering). In the classical rotozoomer slopes are linear. In this part it isn't linear, regularly modified DX, DY added. Nice, but not finished. Eg. there is a bug (FEATURE) in the calculation. I don't change parameters, but looks like it changes every X frames. Maybe some sign problem but I don't care about it. When I added credits part to this effect, I realized main effect and credit changes are in sync. I'm lucky! :-) Also with starting and finishing copiing BMP lines to screen... An hour before the deadline, I no longer felt the urge to pay so much attention to this. But things turned out just the way that everything worked out perfectly. I explain what I mean: Finished all drawing before VIC reaches first line of the credit gfx. Adding all sine data can not be determined easily where finished, but all credit text still on the screen. Unfortunately I forget to ask a texture for this part from Poison, and remains an example image what I used in develop period. She is Ksenia Pobuzhanskay the singer of my favourite folk metal band Alkonost. |
Summary
Submitted by vincenzo on 11 September 2023
| Probably the first demo for Ultimate64 48MHz mode. |
|
|
|
 | Search CSDb |
|
| Navigate | |
|
| Detailed Info | |
|
| Fun Stuff | |
· Goofs (1)
· Hidden Parts
· Trivia
|
|
| Forum | |
|
| Info on other sites | |
|
| Support CSDb | |
|
 |  |
|
![Ultiverzum [ultimate]](/gfx/releases/235000/235349.gif)
