Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
  You are not logged in - nap
Better   [2012]

Better Released by :
Onslaught [web]

Release Date :
10 June 2012

Type :
C64 Demo

Released At :
Flashback 2012

Achievements :
C64 Demo Competition at Flashback 2012 :  #2

User rating:********__  7.5/10 (22 votes)   See votestatistics

Credits :
Code .... Algorithm of Algotech, Onslaught, svenonacid
  Conjuror of Onslaught, Vandalism News Staff
Music .... Algorithm of Algotech, Onslaught, svenonacid
  SoNiC of Onslaught, Smash Designs, The Art Project Studios, The Obsessed Maniacs
Graphics .... Algorithm of Algotech, Onslaught, svenonacid
  CONS of Onslaught, Tristar & Red Sector Inc.
Charset .... B-Wyze of Hardcore, Onslaught, Success
  CONS of Onslaught, Tristar & Red Sector Inc.
Test .... Jazzcat of First Blood Entertainment, Onslaught, Onslaught-Antiques, Vandalism News Staff
Help .... Jazzcat of First Blood Entertainment, Onslaught, Onslaught-Antiques, Vandalism News Staff


SIDs used in this release :
Better(/MUSICIANS/S/Sonic/Better.sid)
Breaking the Ring(/MUSICIANS/S/Sonic/Breaking_the_Ring.sid)
The Origin Sound(/MUSICIANS/S/Sonic/Origin_Sound.sid)

Download :

Look for downloads on external sites:
 Pokefinder.org


Production Info
Submitted by algorithm on 11 June 2012
hanks to all the positive comments here.

Some info in regards to the production of this demonstration

After finishing algotecher, I had joined onslaught, this is where the idea of 'better' came along.

Was listening to a great paul hardcastle soundtrack by the name of 'better' and i asked sonic whether or not he could do a cover of it.
He agreed, and the result was outstanding that i decided to put together a demo by this name.
For some reason, the madonna 'who's that girl' video cropt up in mind (dont ask me how, it just did)

After the intro was finished, i included a few additional parts (most of them really being 'fillers') and it was then when conjurer contributed two of his nice demo parts
(which are the x4 fli zooming face and tech tech)

personally, the only two parts which took the longest was the intro and the main striptease part due to the data preperation.
The majority of the second side of the demo was all done in half a day or so including the dreaded linking

I know some people frown on animations. But my opinion on all this is that if it achieves its visual objectives, then it does not matter how it is coded at all!
A severe exception to this would be using animations to create a good looking part but it consuming too much disk space. If the data is encoded in such a way that it uses less
disk space and processing time that what it would take to create pure calculated code, then why not use it?

I frown on this sometimes, but when having short time frame to complete something (bearing in mind that i work all hours of the day and have other commitments) i do sometimes take
the short cut route. Demo coding is all about cheating right? :-) Besides, part of demo coding is creating custom programmes on PC to do the 'hard work' to ease the
load (or try to ease the load) from the C64.

below is some indepth information in regards to the parts

INTRO
-----

The onslaught logo is a charbased image followed by a multiplexed sprite overlay with the title 'better' and a multicolor bitmap underlaid

Each frame of the madonna sprite uses 192x200 pixels consisting of around 80 multiplexed sprites each frame. Data is decompressed and plotted on the fly attempting to ensure
that the designated frame rate is reached. Additional nightmare was the multiplexing to ensure there is no flicker. Two options were present at this moment which
would have been to plot sprite banks in another char bank and switch $d018 at the right time or to use the half sprite method. I decided to opt for the first method and
utilising a variant of the half sprite method on the badline section of the screen.
VSP was originally planned for the background scrolling, but did not like the idea of instability. Hence software scrolling of 2000 charsets (2 buffers) are used. Not an issue as the scroll is at 2 pixels a second allowing me to transfer the data within 4 frames

The compression of the sprites is very basic, where there are empty sections, these are removed and sprite definitions all condensed together. A byte table of 80 values contain the sprite offsets to use to build the image

The background itself is a VQ encoded image consisting of 8 screens. The entire background and text is condensed into 256 characters and everything compressed rather well
The madonna animation was created by screen capturing the animation frames and then removing the background and manually pixeling over the lines, converting and filling to 3 colors and converting to sprite sets

Average time spent including all design, pixel conversion, tool creation for compression, coding: 6 hours


MADONNA SCROLLER
----------------
This could have been a lot better, it was merely a filler while the next part is loading. 4 screens high vq encoded image (it shows 3 screens, but half of the top screen was blank hence left it at that. Updating per frame without using linecrunch, Not an issue of course due to far less data transfer requirements than bitmap

Average time spent on encoding, coding : 30 minutes

ROTOZOOMER
----------
Looks nice doesnt it? (Well it was merely intended as a filler) and totally relies on the pc side of the encoding to achieve its objective) PC code is merely plotting specific charsets to achieve the effect

Average time spent on encoding, coding : 30 minutes

KEFREN PART
-----------

Creating 160 pixel true kefren would eat up all CPU time and would be rather small. I decided to exploit the nature of the data to encode straight sections of the kefren data into a bit based format. The result is a wider kefren based data updating each frame. the curve sections are vq encoded but could have been much better if using more definitions.

A text display effect is also before the part consisting of bit based seek and char plotting to gradually display the text

Average time spent on encoding, pc tools to encode data, coding : 1 hour


AMIGA MODE FADER
----------------
I had previously created a conversion tool that converts data using a different technique in comparison to the standard - reduce colors, then reduce to format.
Genetic mutation approach has been used to place specific pixels next to each other based on the limitations of the c64's gfx mode and then performing a 'blur' fuzzy comparison. process is repeated until less errors are encountered. This results in imagary that consists of far less errors than the original image (and looks better!)

The actual mode used is my standard MUCSU mode which consists of multiplexed 8x10 underlay sprites) I have incorporated fading and defading into the routine as well

Average time spent on coding : 30 minutes. Pc tool creation time not specified (was on and off for quite some time)


MEMBERS PART
------------
The first section of the member part consists of the same video compression routine based on the intro sequence of the spinning woman in algotecher. All compressed
data packed in around 3k.

The second section has over 22 full screen 320x200 multicolor pictures. I used a tweaked version of my encoder that is able to analyse individual faces and use
that for generating an 'optimum charset' This results in 22000 8x8 pixels being converted to 256 8x8 pixels.

Average time spent on coding and encoding :1 hour

ONSLAUGHT LOGO
--------------
Bitmap defader and fld

Average time spent on coding : 10 minutes

FLIX4 ZOOMER
------------
Conjurer kindly provided me with this code. True 4x4 FLI realtime zoom with various effects and multiple face zooms

CHARPIC 1
---------
A filler while the next part is loaded. VQ encoded image

Total time spend on encoding / coding 20 minutes

VECTOR 1
--------
Edge detection and shade detection values of each freezeshot were encoded using my encoding tool. This results in the ability to fill and edge encode 32 pixels using
look up tables. runs at 25 frames per second

Average time spent on encoding, coding: 1 hour

FRACTAL ZOOMER
--------------
As i may have mentioned at some stage before, i have created a tile based compression method which can use 1 byte of data to plot 16x6 pixels of specific definition
onto the screen.
The zoomer contains predefined values of less than one block uncompressed which points to a lookup table consisting of a 4 byte value which in turn points to a memory offset
which contain the 4 8x8 tile values to plot onto the screen

This process is repeated to build the frame.

Routine runs at 50 frames per second

Time spent on encoding, coding 1 hour

COLOR BLEND MANIA
-----------------
An updated version of my MUCSU-FLI converter (Not released yet) Resulting in less errors and higher image quality
FLI every line with sprite underlay

Time spent on coding. 5 minutes (uses display code from previous routine) Not including updating pc tool

TURNDISK
--------
VQ encoded animation

Time spent on coding 5 minutes


COLOR VQ
--------
Due to time constraints, i merely reused the routine from my previous algotecher demo and reencoded the data with another animation sequence

Time spend on encoding 1 hour


GREETS
------
Not happy about this one at all. None the less consists of font plotting flickering each into place.


Time spent on coding 30 minutes

CHAR PIC 2
-----------
Exactly the same routine as previously on side 1. but with a different vq encoded image

Time spent on encoding 10 minutes

256 PIXEL TECH TECH
-------------------
Conjurer kindly provided me with this code. Consists of smooth 256 pixel x position tech tech in all 200 lines.

INTRODUCING PIC
---------------
A MUCSU encoded image introducing to the forthcoming part

Time spent on encoding 10 minutes

STRIPTEASE
----------
Ok, now this is the main part of the demo. Will describe each section of what goes on in the background starting with how the data is encoded via pc

I have created an encoder that is able to encode and compress video to around 80-150 bytes a second. It works via motion static reduction preperation followed by clustering
16x16 chunks into 256 'optimum' seperate definitions utilising face detection based VQ. It then iterates the whole data to encode 256 individual charsets using the 16x16 data.
This ensures that each 2x2 block (consisting of 16x16 pixels) can be represented by 4 lookup bytes pointing to a 8x8 pixel charblock.

This then results in a 2k gfx block followed by framedata information as well as a 1k lookuptable.


Where it differs from my previous Video encoding and decompression method (Used in VQ mania) is that the lookuptable data is dynamic (hence rather than having to use a different charset for later frames, 1k of data is sufficient

The data is then semi-compressed via motion delta estimation with motion data being stored 1 bit per 16x16 pixels.

The decoders purpose is to read the compressed framedata, decompress it into 240 bytes (which is 20x12 bytes) and then perform the 'tile stretching' which consists of each byte value in the decompressed stream pointing to the relevant 1k lookuptable. This in turn points to the 4 bytes that gradually build up the screen

But now we want digitized audio...

The idea was to have 7812 samples a second sample rate, but this would have resulted in more data being required for the audio, as well as not being able to stream the data suffiently (unless i used a completely different method of video / audio compression.) as i was half way through, i decided to opt for the method of updating samples once per 4 raster lines instead.. This halves the sample rate but leaves ample processing time for streaming of data from disk as well as video decoding.

Due to the flexibility in the additional cycles, i have used what is known as 'twinvq' (please dont confuse it with the yamaha twinvq). The decoder handles two individually compressed audio streams (at different block sizes) and mixes these in realtime. I did not have to change any part of my audio encoder in order to achieve this, it was merely compressing the background at a different block size seperately than the speech.

I used a very high compression ratio for the speech (around 1.2kbs equating to around 120 bytes per second)

The 8 bit audio playback method is used which means that each updated sample requires a minimum of 20+ cycles just for the audio setup, not the less plenty of cycles available.

There are a lot of optimisations that could have been done, in both audio and video parts.

The audio part, i have not used the jump to ddoc method, additionally used the jsr opcode in the nmi... bad bad idea,
The video tile decompression part, could have sped up the routine by x2. but yet again, speeding up the routine with no data there to speed it up is not a good idea.

Including the audio and video decompression, this still leaves an ample amount of cycles for krills loader (which is the ultimate in loaders no doubt)

Total time spent on encoding / experimenting with routine (30 hours) Total time coding 2 hours



END PART
--------
Up scroller with the credits

Total time spent on coding 10 minutes


Then ofcourse the linking which was an additional good few hours on top of that


Phew. Well i hope the above gives a brief insight to what was involved in the creation of the production. 80% of which my PC encoding tools were responsible for encoding












Search CSDb
Advanced
Navigate
Prev - Random - Next
Detailed Info
· Summaries
· User Comments (36)
· Production Notes (1)
Fun Stuff
· Goofs (1)
· Hidden Parts
· Trivia
Forum
· Discuss this release
Support CSDb
Help keep CSDb running:



Funding status:




About this site:
CSDb (Commodore 64 Scene Database) is a website which goal is to gather as much information and material about the scene around the commodore 64 computer - the worlds most popular home computer throughout time. Here you can find almost anything which was ever made for the commodore 64, and more is being added every day. As this website is scene related, you can mostly find demos, music and graphics made by the people who made the scene (the sceners), but you can also find a lot of the old classic games here. Try out the search box in the top right corner, or check out the CSDb main page for the latest additions.
Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.15 sec.