matosimi

One of the early versions - NSFW alert!

based on your experience it seems the prior version without fix was distributed: unfortunately I have designed the "level" like 10 minutes before the deadline and uploaded to the "upload space"... then I tried it, found and fixed the bug, however it was after the midnight and upload space was gone.... so I uploaded it to the chat we had with @holgibo ... which got accepted, but apparently forgotten.

I have used gtia modes in multiple game projects in quite different way, you can check and download from my signature below this post. Light up! - black&white title screen tip image (alternating gtia9+gtia10 lines) H3x0r deluxe - coloured title screen tip image (256 colors alternating gtia9,gtia11,gtia10,gtia11) Quarrion - main game screen running in gtia10 (character mode) Citron 3kg - main game screen running in gtia10 (bitmap mode) Lasermania 2020 - in-game horizontal lines of colored frame in gtia11

Abbuc version of QBF:

Q.B.Fox Colors: 22 PAL Title screen image from my latest ABBUC SWC entry. matosimi_QBFox.xex

hey @bocianu, would it be possible to implement something like add 1 line or remove 1 line from the sprite frame at a desired position? so in case of add: -> and in case of remove: -> alternative option would be to re-parse data in the export window... so i will be able to edit the data in the export window and import it back as a new frame/set of frames...

I just tried the new mads feature for me (learned yesterday) in my project and it did not finish well... i switched: to the compilation looks ok: however the binary crashed and chkxex.exe output is: ...the version with "org" compiles ok and chkxex.exe also works and the binary works. there is an issue within the xex blocks...these are the first 3 blocks of the "org" version: block 002 is basically the part in the screenshots above.. where the get_byte is stored at $9ffe, but assembled at $cb ... and relocated into ZP later. the output binary when .local player,player.playerzp is used has following couple bytes at the beginning: so it looks like block 001 starts from $9b00 to $00d4 ... and that is definitely incorrect. -> reason also for the runtime error in the chkxex.exe. I tried switch from ORG -> .LOCAL name,address to see if the blocks 001 and 002 get merged into single block.

Yes, but this has already been defined at the beginning of fk_title.h which is included at the beginning of fk_title.asm.

@flashjazzcat I am experiencing kind of similar issues with the scopes for a long time (more than 10 years), but I am using some workarounds here and there. The most surprising issue is when I am incorporating some g2f into my game inside a .local like here with the fk_title.g2f: portb equ $d301 org $2000\ mva #$ff portb\ rts\ ini $2000 org $9000 jsr g2f.main jmp * run $9000 .local g2f icl "fk_title_altered.asm" .endl -> fk_title_local.asm G2F picture is simply saved as ASM Assembler File ... in fact several files, one of them is fk_title.asm. I create an altered copy where I move init block outside into my main code and I also remove the "run" command. when I try to compile code above, I get an error: mva #@dmactl(standard|dma|lineX1|players|missiles) dmactl ;set new screen width fk_title_altered.asm (291) ERROR: Undeclared label STANDARD (BANK=0) Writing listing file... This is the way how I fix it: ;mva #@dmactl(standard|dma|lineX1|players|missiles) dmactl ;set new screen width mva #scr40 dmactl No idea why it does not it work out of the box. also in if the color fade is in use, there is another instance of weirdness in fk_title.fad: "fade" is the name of the .local at the beginning of the file... and I have to put there a new label like "xx" just after the .local definition: ...and replace jmp :fade with jmp fade.xx .local FADE_OUT ldx <fade ldy >fade jmp fade.xx ;fix You can try on your own: fk_title_local.zip G2F is quite widely used, and I often use several G2F pictures in my projects, I have to put each of them in separate .local scope...together with these fixes, it is quite surprising that no one else has reported these issues. I also have issues with my own macros called within another macros within some locals... so the labels within macros are reported as unknown. In those cases I unroll the deepest macro level to overcome the issue. Unfortunately I cannot create simple example, because it always pops up quite later when my project gets bigger and more complex... throughout the years I could not find the exact moment when that starts to happen... ...but at least I know how to overcome it.

Also CMC is using several of these key combinations: ... But why don't you then assign like whole line of keyboard keys and use whatever works? I'm pretty sure there will be barely noone else doing what you are, so I would not take care about SW I don't use.

Not sure what you mean by 'available', however generally there are like 10 keys that are inaccessible together with control+shift key combination. See the bottom section of the following table: https://www.atariarchives.org/c3ba/page004.php

I have tried cc65 long time ago and it was painful. You can read the stories here: http://matosimi.websupport.sk/atari/?s=Cc65 You just have to translate the pages :), back then I was writing articles in Slovak. there is definitely way to optimize/write the cc65 code to compile faster and shorter, but I'm not sure if it then it's similarly long leaning curve compared to writing directly in ASM. I have been struggling with IDEs, however that's normal when using C. If you are not a C coder, I suggest to not even trying. if there were mad pascal existing at the time I was coding Roxblox, I would 100% go for it. also the generated code is better translated (faster,shorter,more readable) to 6502 ASM code. The only drawback is the evil block definition with begin/end that I really hate. So in nutshell: lot of subjective stuff against cc65, no real experience with mad pascal at all.

Fallen Kingdom v1.2 has been released... updated NTSC colors + altirraOS crash fix of ending screen: http://matosimi.websupport.sk/atari/2024/03/fallen-kingdom-v1-2/

@popmilo, nice work! I have encountered just 2 small glitches in the sprite deletion... 1) tony_x1.atstate2 The bat on this screen can kill you when climbing the ladder, when it's removed (either by killing you or you killing it) it deletes the 1px wide area from the ladder together with the bat sprite. I assume this is the only place where bat or other flying enemy can kill you while climbing the ladder. 2) tony_x2.atstate2 The skull on this screen leaves couple pixels (1 line) when killed... it needs couple tries to succeed to leave the mark. I'm not sure whether it is worth chasing these bugs, nothing that important... I think 1st could be fixed simply by removing last position from bats path. However I'm not sure whether it remains lethal to the player climbing the ladder. 2nd could be caused by the fact that the skull, two bats and Tony overlap single vertical position, so sprite drawing routine does not handle all the redraws at the same time. Good luck with the rest of the project!

something like this?