Linerider ASM

[luby]

I have finally talked myself into it. I am going to start making Linerider ASM. I will ask for help as I am new to ASM
Stuff to do:
1. get an explanation of how to draw check
2. make drawing routine check
3. make zoom in feature (Easy) check
4. actual engine w/scrolling (hard) working on
5. multiscreen
6. saving working on
7. Title Screen

Any volunteers/helpers/good friends?

[Noob88]

I'd love to help, as I am a huge fan of your game, but I'm not very experienced in asm I probably wouldn't be much help to you.

[frenchcalc1]

Sorry, I'm still learning ASM...if I could, I would volunteer

[Iambian]

1. draw what? Lines? single pixels? circles?
2. depends on what you want to draw.
3. any zooming feature is slow to implement. Specify exactly what you need in detail.
4. Uhm...
5. Split your buffer up appropriately and draw only to those sectors.
6. Copy your current configuration of whatever you need, be it a table used to keep track of variables or whatnot into an appvar of a size and name that your program creates itself (the SDK will help with that), or rely on a shell, like ION, to use its writeback feature if you want to keep the data persistent in your program.

[luby]

1.I'm going to need to draw pixels (in lines), but to do that, I will need an explination of doing so.
2. draw pixels using 1-9 keys (see above) and inputting the cooridinates to an array
3. not really, I had a pretty fast prototype in basic. Just multiply the array by 2 and redraw the current lines on the graph, just as 2x2 boxes instead of single pixels
4. I'll take care of it.
5.???? the seperate screens exist in seperate pics (at least in basic)
6.pics (or configurations of the pixels) need to be stored.

[Iambian]

1. To draw a pixel on the screen, you need to know that the entire screen is kept on a buffer 12 bytes on a row, with 64 rows on the entire screen. 12 bytes is needed because each pixel can be represented by a single bit, and there are eight of those in a byte. 12*8 = 96. To draw a pixel to the screen, you first need to figure out where on the buffer you're going to draw. For this, the origin of the "graph" is at the top-left corner of the screen (I say "graph" because we don't deal with negatives. It's just the values.) For each Y value from 0 to 63, you multiply that by 12. In Z80 ASM, this is accomplished by adding the number by itself twice (x4), saving that number, adding to itself again (x and then adding what was saved (x4 + x8 = x12). For the X coordinate, you divide the number you seek by 8 to obtain the particular byte you need on that row. To do this, you need to right-shift the byte three times. Make sure that you catch the remainder into another variable and reshift it so that it reflects a value between 0 and 7. Save this number for later. You add the quotient of the division with the result of the multiplication and then add into it the address of the buffer (which may be plotsscreen) to obtain the specific byte you need. With the remainder that you saved, you will then get a bitmask, depending on whether or not you want to write or clear a bit and rotate it left as many times as indicated in the variable. Other people will use a small lookup table to retrieve this preshifted mask beforehand. Depending on the mask, you will now want to OR or AND the contents of the pointer to the buffer and the write back the result. You'll want to see code for more details (not posted cuz I'm lazy)

2. Uh... yeah.
3. What I meant to say was that it's slow if the numbers you have to work with isn't nice (i.e. powers of two). In ASM, it should be lightning-fast (though I haven't tried to make something like that yet, so I dunno)
4. Scrolling might be accomplished by a simple shift across the entire screen, or at least parts to it.
5. I still don't understand this "multiscreen" concept. Please expound upon it.
6. You could just let automatic writeback handle the mess. All you have to do is write the information directly into your program. One surefire method is to have all your variables contained within the program itself as opposed to in saferam.

[luby]

5. See? when someone draws to the end of the screen, it goes to the next pic in line.

1. Thank you. I think I get it now. A little snippet of code will help, like putting a pixel on 45,23 or something.

[benryves]

Ion provides a function that will retrieve the bitmask and address of the byte a pixel is "in" on the graph buffer (ionGetPixel).

[luby]

Bueno. To use that, I would need the Ion inc file, right? could I use the Mirage Os inc?

[benryves]

MirageOS supports all Ion functions, though for some reason changes the name (so that'd be iGetPixel, IIRC).

Writing your own wouldn't be very difficult. The offset into the graph buffer would be (y*12)+(x/+plotSScreen, and the bitmask would be $80>>(x%8 ).

[Liazon]

I've been a bit busy, but I really wish you lots of luck since the basic one was really good

[luby]

I'll have lots of time this next week to work on it (spring break). I'll be on the IRC if I need help.

[luby]

[frenchcalc1]

Well, since I don't know much about Asm, I would guess that the

[luby]

It doesn't have anything to do with that.

It has to do with the includes and "duplicate label "& "forward reference in equate" errors.

[Harrierfalcon]

Actually, it's probably caused by you including ion.inc AND the 83plus equates. All Ion progs I've seen only include ion.inc, which leads me to believe that ion.inc already has the 83plus equates.

[frenchcalc1]

[kermmartian]

/me starts up the "Write it for DCS!" chant. Good luck with this.

[luby]

When I only incude Ion.inc, I still get 24 errors. I am trying ion studio, so I'll keep you posted.

[luby]

I am officially disowning ION as it doesn't like me. My computer is a little sick right now, he caught a cold (I caught him "exchanging data" with our neighbor's computer. He claimed he was only "studying circuitry".) I will have limited access for a few days.

here is a screenie of possible sprites


Is this how to pixel test?