[ / / / / / / / / / / / / / ] [ dir / 3s / acme / animu / jewess / mde / tacos / vg / vichan ]

/agdg/ - Amateur Game Development General

AGDG - The Board
Winner of the 77nd Attention-Hungry Games
/x/ - Paranormal Phenomena and The RCP Authority

April 2019 - 8chan Transparency Report
Name
Email
Subject
Comment *
File
Password (Randomized for file and post deletion; you may also set your own.)
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Embed
(replaces files and can be used instead)
Oekaki
Show oekaki applet
(replaces files and can be used instead)
Options
dicesidesmodifier

Allowed file types:jpg, jpeg, gif, png, webm, mp4, swf, pdf
Max filesize is 16 MB.
Max image dimensions are 15000 x 15000.
You may upload 5 per post.


Welcome to AGDG, have you ever made a game?
See also: /ideaguy/ | /vm/

YouTube embed. Click thumbnail to play.

2971d3  No.31939

Hi /agdg/ In this thread I'll show you and talk a bit about my demo for the Commodore 64. It is not a game and if you think it shouldn't belong here you can remove it, but /tech/ is full of dev larpers and /v/ seemed interested in the demoscene when I made 2 or 3 threads some time ago.

The embeded video shows the current state of the demo. Two 99% finished parts and a third one which is almost done, there's just some design work to be done yet. My plan is to make 5 parts + an end part and release it.... hopefully soon. In the next posts I'll talk about some technical details.

2971d3  No.31940

I don't know how much into the details I should go but briefly about the computer itself:

6502 based, 8-bit CPU with about 1Mhz clock

Video chip (VIC II) with 320x200 resolution, 16 colors, 8 hardware sprites (and much much more when treated right)

Audio chip (SID) with 3 voices, 4 waveforms (and more if you toggle 2 waves at the same time, you get some strange but usable shit), analog filters, oscilator sync etc... powerful synth chip.

64kb of memory

5 1/4" floppy drive (170kb per disk side)

On the paper, doesn't seem like much, but C64 coders prove that it can do much more.


2971d3  No.31941

CPU is synced with the video signal and VIC does support raster interrupts so you can know exactly when is your code running. The chips are designed in such a way that it seems like you were supposed to set some registers once in a while and leave them alone, but because the C64 memory sharing is so clever and you can run your code while the video chip is drawing the screen, you can change these registers on the fly. That's when really interesting stuff happens.

Most of the C64 raster effects work on playing with "bad lines".

In contrast, on the NES for example, when the screen is being drawn, the video chip takes the whole memory bus for itself and the CPU is stalled, your code can only run after the drawing was done (in the vertical blank period). On the C64 the CPU and VIC II share the bus. Ram is twice as fast, so on one cycle the CPU gets the bus and on the other the VIC gets the bus. However, on every 8th line VIC has to read more data, so it is stealing the bus for itself and the CPU is stalled during that period. This is the "bad line". The characters are 8x8 pixels big, so on every first line of the character VIC has to read the indexes of the chars.

Because you can scroll your image down by 0-7 pixels, the rule for bad line can't be hardwired to specific line number, it has to be the first line of the characters, so the rule for badline is :

if the lower 3 bits of the line counter are equal to the Y scroll register it is a bad line... for example:

Y scroll 0 : bad line is at 0, 8, 16...

Y scroll 5 : bad line is at 5, 13, 21...

You can change the Y scroll whenever you want, so what if you intentionally change the Y scroll to never match the line counter ? What if you force bad line on every line ? What if you force a bad line in the middle of the screen ? There's a lot of outcomes.


2971d3  No.31942

File: fc55b6bf72bb6b8⋯.png (58.81 KB, 750x509, 750:509, dustlayer.com-screen-raste….png)

Here's a small explanation of the effects seen in the video.

The first words are moving up and down. This is done with FLD (flexible line interpretation). That is, changing the Y register in such a way that the badline doesn't occur. When it doesn't occur, VIC doesn't have any graphics to draw (except the background color) and once the badline is triggered it resumes drawing like nothing happens. In my code I avoid badlines more or less on every frame which makes the movements.

The drawing of the letters and later the bitmap is simple memory coping, to save cycles and make the whole thing faster all loops are unrolled. To save the executable space, these loops are not unrolled in the binary, but there's a small piece of code that generates these loops and then jumps there (code generators)... C64 doesn't have cache, there are no protections. Code Is Data and Data Is Code. Mixed patters of code and data and self modifying code is bread and butter of C64 demo making.

Now you might have noticed that there's a big border around the screen, but when the first part starts proper you can see the scrolltext and logos in the border area. Well, you can open the borders and display sprites there.

The border is split into 2 parts, the top and bottom part (in green) and the side borders (in yellow). The screen inside is 320x200 pixels (40x25 chars 8x8 size). Opening top and bottom border is very easy. Side borders work on the same principle, but require cycle perfect code and you have to do it on every line you want to open. In my part, I have the side border open only for the 16 lines of the side scroller and for about 40 lines in the bottom for the dancing logo. (to be continued)


30f3fe  No.31943

File: 66218a2f8fbfaf2⋯.webm (10.58 MB, 532x300, 133:75, Jeroen Tel - _After Burne….webm)

Which SID are you using 6581 or the 8580? If it's the 6581, you could put samples in the track, webm related. I also liked how the first part the distortions of the bottom text were in sync with the music.


2971d3  No.31944

YouTube embed. Click thumbnail to play.

>>31943

8580 which can play better samples than 6581 with new techniques, 8 bit samples at 16khz is quite easy and is being used more and more in the modern demos, one even does it at 44khz (with barely any visuals though) there's also algo who's really good at vocoder and packing and all that shit and is being able to get around 4 minutes of sampled music with some effects (vid related)

yes the logo stretching is synced with the music as is the colour flashing of it and the scroll. It's sort of accurate, this and the fake 3 bars of equalizer are just reading bytes I picked from the music player that changed in particular way and looked nice enough.


2971d3  No.31945

YouTube embed. Click thumbnail to play.

>>31943

also the tune you posted takes 31 kb and almost all the cpu, there's a reason such tunes were only used for tittle screens. When I pick the music it has to be rather small (10kb at most) and run once per frame, the exception is the first tune made by pvcf for my demo (it's not released yet) and it's played twice per frame, it was a pain to make it work without bugs especially in the intro when changing the color, but it was worth it. Everything else (other tunes and graphics) are old pieces already released, I'm just coding. The logos are some fonts from the internet converted to sprites, I done that myself, the font in second part is also mine (that's why it's so ugly). Having a proper team would be great, but I'm not "advertising " myself in the scene yet, I want to surprise the dudes. I got into contact with pvcf under YouTube comments out of all the places lol. Super glad he made this great track for me.


30f3fe  No.31946

>>31945

I honestly didn't know 8580 was capable to playback samples, also the C64 demoscene is honestly my favorite one to look into just because of how programmers work on an almost 40-year-old machine. I mean I heard composers making Speech Synthesis from the waveform themselves.


2971d3  No.31947

YouTube embed. Click thumbnail to play.

>>31946

yeah, well the old sid had a bug, it makes noise when you change the master volume (4 bits) and so changing the volume continuously gives you a 4 bit playback. Because the cpu is only 1 mhz you can get around 8khz with that.

playing samples on new sid is a different technique, actually there's couple of them but I know only one (just in theory though). There's a bit which you can set and it causes the oscillator to reset, so what they do is play some wave form with specific parameters and then restart the oscillator and pick another wave. It can be computer what waves and when to select to play arbitrary samples.

I will explain some more video effects tomorrow.

Video embedded is first tech tech effect on c64


2d7663  No.32050

YouTube embed. Click thumbnail to play.

Well, it's been more than one day. But here it is. I want to explain the third effect with the scrolltext moving in different patters. It's a fucking clever trick and it makes a lot of cool stuff possible.

On C64 you've got 8 hardware sprites. They are 24x21 pixels big, have their own X and Y registers and you can position them anywhere you want.

24x21 might seem like odd size, but it makes sence in binary form. 1 byte is 8 bits and 1 bit encodes one pixel (bit 1 = color, bit 0 = transparent), so 3 bytes make up one line (3 * 8 = 24) and 21 lines * 3 bytes is 63 bytes. Add one extra and you have 64 bytes aligned sprites. The VIC memory bank is 16kb (from $0000 to $4000 for example) so you can fill it all with 256 sprites (64 * 256 = 16kb). For each hadrware sprite there's a sprite pointer and it's just a byte which is multily of 64 to determine where the graphics are. For example sprite pointer 0 is $0000, 1 is $0040, 128 is $2000

Sprites can also be double with and double height. There's a register for that, 8 bit value, one bit for one sprite. If the bit is 1 the sprite is double with / double hight ($d01d for width $d017 for height).

However, there's a bug in the VIC. If you set the double height register ($d017 = $ff) and then unset it ($d017 = $00) at the line where the sprite is displayed, that line will be doubled. So if you do that trick on every line you will stretch that sprite. That's how the logo at the bottom in the first part with dog is stretching. I am doing this $d017 trick more or less on every frame which makes a stretching movement.

Now the scroller in the third part is done with "FPP" Flexible pixel position, meaning on every line of the screen you can display any line of graphic. With that setup, it only depends on what line and where you choose to show, so I can do stretching, moving it upside down, repeating the logos, spliting it every line to make "blinds" effects etc. But how do you do that ?

You set up your sprites next to each other, but one pixel higher than the previous. You start your stretching code at the line where first sprite beggins. Now because the other sprites are 1 pixel higher, you will stretch the first line of first sprite, second line of second sprite (first line will display normal because it's before the code) third line of third sprite (2 lines normal) and so on.. Now do that on every line down the screen. In my demo I do it for 120 lines. So now you have 120 lines of repeated graphics. In addition to doing the $d017 trick you set a different sprite pointer on each line, so on each line you are changing what the sprite graphics are... Now all you need is specially crafted sprite graphics. Remember, you are repeating first line of sprite 1, second line of sprite 2 and so on, so what if i make a sprite graphic that has 8 lines (rest doesn't matter) and they are the same one line of my graphic i want to display (logo or letters of a scrolltext), then make another sprite where the 8 lines of it display the second line of graphic. And make as many sprites as you want (I make 21 because my font is 21 pixels high). Now let's say on line 1 you set all sprite pointers to 0, it will take the first sprite graphic, it shows the first line of your logo/text, on next line select sprite 1, it shows the second line of your logo/text... and so on.... Make the code read the sprite pointers from a table. Now you can just fill that table with whatever numbers you want, it will display that graphic. All the moves I do in that video use different functions to fill up that table in different ways and there's more possibilities for sure.

Because it is not a constant logo but scrolling text, I have to make these special sprites (where first 8 lines show the graphic line I want) on the fly. I have 7 sprites, 7 letters on the screen and I prepare 21*7 sprites. It takes a lot of CPU... If it was a constant logo I could easelly cover more screen or make more complex calculations. Check out this demo effect. It uses the same technique, but it also opens the side borders and scalles the graphics ! Sick stuff. (7:50, sorry no webm but I'm on a phone)


278e00  No.32175

YouTube embed. Click thumbnail to play.

I'm working on a new demo part and this is what I have so far. Pretty cool (in my opinion) sinus dots in 4 colors. About 900 dots moving around. Uses 4 sprites with just 2 dots as their graphic and moved around on every line with raster code.


278e00  No.32195

File: 6acfd8683cbecd7⋯.webm (8.06 MB, 710x536, 355:268, demo5.webm)




[Return][Go to top][Catalog][Nerve Center][Cancer][Post a Reply]
Delete Post [ ]
[]
[ / / / / / / / / / / / / / ] [ dir / 3s / acme / animu / jewess / mde / tacos / vg / vichan ]