Cybearg

Typically, titlescreen logic is separate from level logic, so while it doesn't actually matter, most likely people will go titlescreen->level 1->level 2, etc. for the sake of semantics. If you haven't already, I'd recommend reading through RandomTerrain's excellent batariBasic documentation and checking out the examples.

In that example, monsterskilled is just an arbitrary name for a variable. You set variables like so: dim monsterskilled = a Typically, people define all their variables like that before any code. The "dim" just means that you're defining a name for some memory. a-z are the names of variables that have been made available to you in batariBasic. Think algebra. Just like you can write a + b = c, you could also write monsterskilled + tummiestickled = laughsgiven, or any other combination of words. It's just a name to represent the number in an abstract way. All you need to do is let the compiler know what those words (variables) refer to, which is what the "dim" statement is for. That's why you were getting a black screen: the compiler didn't know what "monsterskilled" meant.

What did you do to get it working?

It's not, so this probably won't work as expected. In batariBasic, score is actually 3 BCD bytes, which means that the bytes go from $00 to $99 and each of those hex nybbles is read like the decimal digits 0-9. However, if you tried to divide them, you wouldn't get the same result: 99 / 2 = 49.5 $99 / 2 = 76.5

Yeah, but I think I was doing something else wrong. I just went back to things again. This time, I tried something different: 1. I deleted all files from the project directory except for mowleco.c, tiles.c, and the run.bat and make.bat files 2. I switched to view files by Date Modified, so I can see the most recent files as they're created at the top. After that, I tried CCI3 first: 1. I opened CCI3 2. The "learning" folder was selected by default, so I clicked mowleco.c and then Compile: Files created: mowleco.sym, mowleco.rel, mowleco.lst, mowleco.asm 3. I then chose tiles.c and hit Compile again: Files created: tiles.sym: tiles.rel, tiles.lst, tiles.asm 4. Next, I clicked Link: Files created: result.rom, crtcv.noi, crtcv.noi, crtcv.map, crtcv.lk, crtcv.ihk 5. Finally, I clicked Run. However, since that doesn't automatically open the ROM (for some reason), I had to navigate to it and select it. 6. This time, I saw a change, which is great! That worked! Maybe I hadn't clicked on each of the files (mowleco.c and tiles.c) and compiled both before linking. Alternately, after deleting all but the bat and c files, I tried CCI2 through make.bat: 1. I opened make.bat, which opens CCI2 2. I clicked "Default" as advised, which selects crtcv.rel, cvlib.lib, and getput.lib 3. Next, I clicked Compile All: Files created: mowleco.rel, c.bat, and tiles.rel 4. Then, I clicked Link: Files created: result.rom, l.bat, crtcv.noi, crtcv.map, certcv.lk 5. Finally, I clicked Run (which works) and saw the expected change. Woo! So maybe I was just doing something stupid and not realizing it. Is there any reason to use CCI3 over CCI2? Why do such a different set of files get created? Why does the Run option in CCI3 not work correctly?

Since this thread is about getting started with programming, I might as well ask my stupid questions here... I went to Sebastian Mihai's website to get the Coleco C dev kit and put it in C:\z80 as instructed. I saw that he included his Mowleco game, so I duplicated the directory and renamed it "learning," with the intent of fiddling around with it until I get an idea of how stuff works. I run CCI3.exe and "learning" shows up as expected. I click "Compile All" then "Link" then "Run." The emulator pops up, though I have to select the result.ROM file by hand (mildly annoying). It works... but it doesn't actually reflect any changes I made to mowleco.c. Likewise when I try make.bat from the "learning" directory and press Default (as instructed) then Compile, Link, and Run. At least CCI2 will open the game in the compiler when I press Run, but, again, the game doesn't reflect any changes I make to the .c file. What am I doing wrong?

Anita Sarkeesian would be pissed.

Can you post what the errors you're getting are? If your compiler's broken, I'd recommend re-downloading the latest version and setting everything up from scratch. Probably best to re-download vbB as well. Do you know what versions you're using? Everything's so scattered, it can be hard to know where the latest versions of things are, but I think that this should have the latest version of everything.

Well, a possible problem is that you have: if missile0y>240then goto skip You probably need a space between 240 and then, or you'll confuse the compiler. Beyond that, I don't see any issues, aside from your lack of spacing. This works for me: birthday.bas Also, you should wrap your code in code tags, like this: rem Generated 11/8/2014 1:13:12 AM by Visual bB Version 1.0.0.554 rem ********************************** rem *<filename> * rem *<description> * rem *<author> * rem *<contact info> * rem *<license> * rem ********************************** playfield: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ............X.......X........... ............X.......X........... ............XXX...XXX........... ................................ ................................ ................................ ................................ ................................ ................................ ................................ end COLUPF = $22 COLUBK = $32 player0x = 75 player0y = 75 player1x = 20 player1y = 20 missile1height=4:missile1y=255 NUSIZ0 = 16 sprites player1: %00100100 %00100100 %10100101 %11111111 %00111100 %01111110 %01100110 %01011010 end player0: %01100110 %00100100 %10111101 %11111111 %00111100 %01111110 %01111110 %01111110 end if missile0y>240 then goto skip missile0y = missile0y-2:goto draw_loop skip if joy0fire then missile0y = player0y-2:missile0x=player0x+4 draw_loop drawscreen goto sprites

On this, and on getting both sprite and color data shared between sprites, I have a question... Here is an example of my current set-up: .L0129 ; on frame goto __Stand __Stand __Stand __Stand __WalkA __WalkB __WalkA __WalkC LDX frame LDA .L0129jumptablehi,x PHA LDA .L0129jumptablelo,x PHA RTS .L0129jumptablehi .byte >(.__Stand-1) .byte >(.__Stand-1) .byte >(.__Stand-1) .byte >(.__Stand-1) .byte >(.__WalkA-1) .byte >(.__WalkB-1) .byte >(.__WalkA-1) .byte >(.__WalkC-1) .L0129jumptablelo .byte <(.__Stand-1) .byte <(.__Stand-1) .byte <(.__Stand-1) .byte <(.__Stand-1) .byte <(.__WalkA-1) .byte <(.__WalkB-1) .byte <(.__WalkA-1) .byte <(.__WalkC-1) . ; .__Stand ; __Stand .L0130 ; player0: LDX #<playerL0130_0 STX player0pointerlo LDA #((>playerL0130_0) & $0f) | (((>playerL0130_0) / 2) & $70) STA player0pointerhi LDA #30 STA player0height . ; I wonder, though, instead of that on...goto using pointers to branch, could I instead have the player0: code just reference a table of hi and lo pointers to the graphics data itself? This way, all it would take would be a duplicate of those 6 lines of ASM and using the same sprite pointer table to allow sprite data to be easily shared across all sprites. without ever having to re-define sprites. I did this in the past with my Piñata collection. In Fixer Fenix, Wrecker Ron can re-use sprites between his left and right side, cutting out any duplication of sprite data. To do this, I had to use a tweaked bit of ASM: asm setRalph LDX ralphstate LDA ralphLlo,x STA player0pointerlo LDA ralphLhi,x STA player0pointerhi LDA ralphRlo,x STA player1pointerlo LDA ralphRhi,x STA player1pointerhi LDA #17 STA player0height STA player1height end ... which referenced a table of sprite data pointers: ralphLlo .byte <ralphStandA .byte <ralphClimbA .byte <ralphClimbB .byte <ralphPoundA .byte <ralphPoundB ralphLhi .byte >ralphStandA .byte >ralphClimbA .byte >ralphClimbB .byte >ralphPoundA .byte >ralphPoundB ralphRlo .byte <ralphStandA+1 .byte <ralphClimbB+1 .byte <ralphClimbA+1 .byte <ralphPoundB+1 .byte <ralphPoundA+1 ralphRhi .byte >ralphStandA .byte >ralphClimbB .byte >ralphClimbA .byte >ralphPoundB .byte >ralphPoundA ... which in turn referenced the actual sprite data: if (<*) < 90 repeat (90-<*) .byte 0 repend endif ralphStandA .byte 0 .byte %00111100 .byte %00011110 .byte %11101111 .byte %11010111 .byte %11110111 .byte %11101111 .byte %11101111 .byte %11101111 .byte %11111111 .byte %01111110 .byte %00011111 .byte %00000101 .byte %00001111 .byte %00000101 .byte %00000000 .byte %00000000 if (<*) > (<(*+16)) repeat ($100-<*) .byte 0 repend endif if (<*) < 90 repeat (90-<*) .byte 0 repend endif ralphClimbA .byte 0 .byte %00000000 .byte %00011110 .byte %11101111 .byte %11010111 .byte %11110111 .byte %11101111 .byte %11101111 .byte %11101111 .byte %11111111 .byte %01111111 .byte %00011111 .byte %00000111 .byte %00001111 .byte %00000101 .byte %00000000 .byte %00000000 if (<*) > (<(*+16)) repeat ($100-<*) .byte 0 repend endif if (<*) < 90 repeat (90-<*) .byte 0 repend endif ralphClimbB .byte 0 .byte %00111100 .byte %00011110 .byte %00001111 .byte %00000111 .byte %00000111 .byte %00001111 .byte %00001111 .byte %00001111 .byte %01111111 .byte %11111111 .byte %11111111 .byte %11100111 .byte %11101111 .byte %11110101 .byte %11010000 .byte %11100000 if (<*) > (<(*+16)) repeat ($100-<*) .byte 0 repend endif if (<*) < 90 repeat (90-<*) .byte 0 repend endif ralphPoundA .byte 0 .byte %00111000 .byte %00111000 .byte %00111100 .byte %00111100 .byte %00111000 .byte %00111000 .byte %00111000 .byte %00111001 .byte %00111010 .byte %00111110 .byte %00011111 .byte %00000101 .byte %01111111 .byte %11111111 .byte %11111111 .byte %10001111 if (<*) > (<(*+16)) repeat ($100-<*) .byte 0 repend endif if (<*) < 90 repeat (90-<*) .byte 0 repend endif ralphPoundB .byte 0 .byte %00000000 .byte %00000000 .byte %00000000 .byte %11100000 .byte %11100000 .byte %11110000 .byte %11110000 .byte %11100001 .byte %11100010 .byte %11111110 .byte %01111111 .byte %00000101 .byte %01111111 .byte %11111111 .byte %11111111 .byte %10001111 ...changing what otherwise would have required sprite definitions for both player0 and player1 into just single sprite definitions, saving a LOT of space. This would work the same for color data. However, those were with 4k games, where I could just add that sprite data at the end of the .bas file in asm...end statemetns and I was fine. In DPC+, I apparently can't directly put the necessary sprite code into the last bank because that's off-limits. Furthermore, the pointers seem a lot more complicated. Is there a way that I CAN include the sprite data to be added in the final bank? Would it just simply involve modifying the includes file to add the sprite.asm file after the bB.asm file? Would there be complications in using tables of pointers in this way for DPC+ sprite data? Also, what are the limitations of using these kinds of pointers? Can you actually create pointers and pointer-pointers using this table >pointer <pointer notation?

Just tested on Stella and on real hardware. I can confirm it works! I didn't see anything amiss, nor did I really modify my code, aside from adding the DPC_EXTRA_DIGITS const. I'll keep the warnings in mind as I move forward. Thanks much, Omega!

I haven't really had the time yet. I started a new job recently, so I haven't gotten any programming done in weeks.

I saw a mention of the stack... How big is IntyBasic's stack, and how can it be accessed? It would be nice if multiple DEFINE statements automatically pushed to a queue. I have a game concept in mind (nanochess knows what i'm talking about) that is only problematic with IntyBasic due to the amount of sprite cards it would require. This is still doable, as long as I keep only current state's cards in memory. For instance (for the player sprite): Stand = 1 frame (constant) Walk = 3 frames Attack = 3 frames Jump = 3 frames Death = 3 frames ... x2 because this is a 16-pixel sprite. Now obviously that's basically all the cards I've got, but if I keep separate states so that when the sprite goes from walking to attacking it just uses a DEFINE statement to swap the cards, it might be doable. However, this would also apply to enemy sprites, which would need to have cards swapped out depending on the enemy's current state. This frame/state monitoring could be very complicated, especially since it won't be done in Assembly. It would be much easier if I could just call DEFINE and trust that multiple statements would be queued for execution on subsequent frames. By the way, how much additional processing time is taken up by a DEFINE statement? Does it essentially gobble up all the spare cycles of a frame?

Couldn't you tweak the interpreter code to multiply the volume value by 8 or something, giving you a range of 0, 8, 16, or 24?

I think this would require an AtariVox. Correct me if I'm wrong.

Isn't that what you want? Non-asymmetrical = symmetrical = mirrored. Asymmetrical = non-mirrored = full playfield. Asymmetry seems to be what you're going for, judging by the title of this thread.

I just tested both frozen.bin and my own bugged game on real hardware--they both work fine. I didn't notice any strangeness whatsoever: no rolling, tearing, strange sounds, or any evidence of the game being caught in any loop.

Even if you can't find a solution to this bug, I hope you release that cleaned up DPC+! Every spare cycle/byte counts!

Any insight on why setting kernel_options collision(player1,playfield) causes trouble with scores greater than 10 digits?

I think I was asking more in a general sense of curiosity. I didn't have anything specific in mind. Sorry for the bother. Good luck with the move!

ScumSoft posted an Assembly function that is supposed to do this sort of thing: MAC COPY2RAM .source SET {1} .destination SET {2} .amount SET {3} .mode SET {4} LDA #<.destination STA DF0LOW LDA #(>.destination) & $0F STA DF0HI lda #<.source sta PARAMETER ;byte pointer increments on write lda #((>.source) & $0f) | (((>(.source)) / 2) & $70) sta PARAMETER lda #0 ;Using DataFetcher #0 sta PARAMETER lda #.amount ;256 bytes copy max sta PARAMETER lda .mode sta CALLFUNCTION ENDM Now, is this actually complete, or is PARAMETER just pseudo-code? I don't see what PARAMETER and CALLFUNCTION refer to. Also, how do I know exactly which RAM locations to overwrite? That is, if I have a number of sprite and playfield definitions, how can I tell which location needs to be swapped out? Also, does the entirely of that 4k of graphics ROM get copied to 4k of RAM in one go, or does it get copied over in smaller chunks as it's referenced?

Thanks for the information! I'll look into it.

In the theoretical sense of, yes, I could learn Assembly and figure out how to do everything from scratch, giving me the flexibility to implement the feature I've requested myself, or in the practical sense of not knowing Assembly or having a lot of time or inclination to learn lowest-level ASM, and thus being limited to what 7800basic can do out of box? Because if the latter, then I really can't make one. For me, the fun comes from programming the game logic, not the low-level back-end memory architecture sort of stuff, which is why I use tools like 7800basic in the first place.

Has there been a chance for scrolling to be added to 7800basic? And would conditional scrolling be possible, so that one can have a GUI that doesn't get scrolled with the rest of the screen?

It's a shame that, with how much detail DPC+ allows, you're limited to just the 4k of the final bank for all sprite and playfield data. Is there any way to increase that amount or to allow sprite and/or playfield data to be spread across different banks? Also, did RevEng ever make a version of DPC+ that takes advantage of ROMS greater than 32k?