CSDb - Latest Forum posts

CSDb Entries: Release id #262051 : Retro Debugger V1.0.0 /spider-j

spider-j — Fri, 05 Jun 2026 17:30:55 +0200

Tried to compile RetroDebugger. CMake throws an Error about missing files.
Also couldn't find the files on github (?!?) ...

CMake Error at CMakeLists.txt:239 (add_library):
  Cannot find source file:

    /home/spider/Sources/RetroDebugger/src/Plugins/FlameTiles/C64DebuggerPluginFlameTiles.h

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm
  .ccm .cxxm .c++m .h .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90
  .f95 .f03 .hip .ispc


CMake Error at CMakeLists.txt:1414 (add_executable):
  Cannot find source file:

    /home/spider/Sources/RetroDebugger/src/Plugins/FlameTiles/tests/FlameTilesTests.h

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm
  .ccm .cxxm .c++m .h .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90
  .f95 .f03 .hip .ispc

MTEngineSDL was build succesfully.

CSDb Questions: Single Tunes / Tracks /iAN CooG

iAN CooG — Fri, 05 Jun 2026 13:56:07 +0200

just send them to me, if worth they can be added to HVSC.
write also which authors you know they could have made them
hvsc.crew@gmail.com

C64 Coding: Nothing going on before X? /NthSt4r

NthSt4r — Fri, 05 Jun 2026 13:11:32 +0200

Made kind of wallpaper for all party people 8-)

https://csdb.dk/release/?id=262064

CSDb Questions: Single Tunes / Tracks /Xidex

Xidex — Fri, 05 Jun 2026 12:18:12 +0200

Hello everyone,

Just a quick question: I’ve found a disk containing individual DMC tracks.
I can’t find these tracks either on CSDb or HVSC etc. but I can clearly link them to a specific scene member or group.
Should individual tracks like these, which have no ‘visual’ content, be uploaded here, or do they belong or uploaded somewhere else ?
Regards, Xidex

C64 Coding: Side border plasmas /Oswald

Oswald — Thu, 04 Jun 2026 21:05:31 +0200

this effect works by exploiting the fact that this plasmas work like this:

screen(currentx,currenty) = colortable( doublesin1(currentX) + doublesin2(currentY))

if doublesin2 ranges between 0..7 it means there are only 8 kind of different gfx lines, you precalculate these 8 lines in the border, and via a VIC trick you display them as doublesin2 dictates

now if you zero out parts of the sine it will (probably) look like that. you get vertical blackouts coz doublesin2 zeroing, and horizontal blackout for dblsin1. where the sine is not zeroed the plasma is still shown kindof, where only one of the sine is zeroed there you get the vertical / horizontal rasterbars.

C64 Coding: Side border plasmas /Cruzer

Cruzer — Thu, 04 Jun 2026 17:53:14 +0200

I'm probably a lamer, but I can't see how writing 0's to the sine would cause this effect. To me it seems like the gfx is splitting up into a bunch of different blocks that are moving around over eachother while getting smaller. But I probably need to code a plasma like this to understand it.

C64 Coding: How do you deal with sprites over heavy cycled effect? /Monte Carlos

Monte Carlos — Thu, 04 Jun 2026 14:45:15 +0200

Long time ago I created a Speedcode with an extra instruction each Rasterline just to compensate the cycles used for a moving sprite. You can then modify the opcode dependent on the position of the sprite to get different cycles per line. However this method is not very effective but still, it works.

C64 Coding: How do you deal with sprites over heavy cycled effect? /Jetboy

Jetboy — Thu, 04 Jun 2026 13:44:39 +0200

Quoting Martin Piper

If it's a relatively short repeating sprite movement pattern, you could store the cycles per line and adjust or pointer to the relevant tweaked routines in a large table.

Yes, a table for each line saying if sprite is there or not. The sprites would be moving a few pixels max from frame to frame so i only need to update few entries in the table.

C64 Coding: How do you deal with sprites over heavy cycled effect? /Jetboy

Jetboy — Thu, 04 Jun 2026 13:37:43 +0200

Quoting Oswald

ok you say the problem is the irq runs for 4 lines.

one way would be to make 4 kind of routines for each Y configuration, of how the sprites overlap with these 4 lines.

That would be 7 i guess as the sprites might start and end during interupt.

Quote:

another way: animate sprite fine movement for 4 pixels within the 2x2 sprites, so the sprites really move in 4 pixel jumps, the 1 pixel movement is animated.

I like this one! I would choose this solution as it reminds me of bob drawing one that i’ve done before and quite understand and it would be super easy to incorporate into the curent code. Just i only have space for 4 sprite shapes.

Quote:

another way: have 2 sprites on the screen EVERYWHERE regardless of the position of your 2x2 sprites, multiplax blank sprites on top / below them too, then the timing is alway uniform.

Ha that is the simplest! I have even thought about it at the very beggining, but i diched the idea for some reason… I know! I was in the period where my depression was hitting harder and i was not thinking clearly. The reason was that i. Do not have space for 5th empty sprite shape… definetly was not thinking clearly back then. Those sprites dont have to be in visible area, so they can have any shape. Somehow i wanted to place them straith above the moving ones :)

I think i have solution i need! It is simple enough so i should be able to implement it without much hassle. Thanks guys! But if you have more ideas, keep them comming, we can still learn something.

C64 Coding: How do you deal with sprites over heavy cycled effect? /Jetboy

Jetboy — Thu, 04 Jun 2026 13:17:19 +0200

Quoting WVL

You would still get some jitter ofcourse. I remember a talk (I forgot which one) about using the timer as an address so when you trigger an IRQ/NMI the CPU jumps directly to an adress that corrects for the jitter. Never tried that though.

That would be Ninja’s talk i guess. The problem with that it is way over my skill :) though Brush is using similar method for a part in our incomming demo for X (i’m already on the way there btw) i will consult source code. AFAIK it needs to be spread across multile pages that would be challenge as the part is really tight with memory setup, but i guess it should be possible to interleave those procedures with existing code maybe.

C64 Coding: How do you deal with sprites over heavy cycled effect? /WVL

WVL — Thu, 04 Jun 2026 12:46:41 +0200

You would still get some jitter ofcourse. I remember a talk (I forgot which one) about using the timer as an address so when you trigger an IRQ/NMI the CPU jumps directly to an adress that corrects for the jitter. Never tried that though.

C64 Coding: How do you deal with sprites over heavy cycled effect? /Martin Piper

Martin Piper — Thu, 04 Jun 2026 10:08:26 +0200

If it's a relatively short repeating sprite movement pattern, you could store the cycles per line and adjust or pointer to the relevant tweaked routines in a large table.

C64 Composing: straight from YOUR playlist /Shine

Shine — Thu, 04 Jun 2026 00:26:13 +0200

♥️
https://www.youtube.com/watch?v=qrHXdFAtDpI
♥️