Would trying to use isprite and fastcopy erase the previous contents of the screen like a stat sprite would?

Don't think so? Unless the screen buffer got erased then you isprited, then you copied to the actual screen?

Nope, it shouldn't, unless you're using a really funky routine.

Maybe it's something that BZC does to the code. I also noticed that if you press clear it takes you to the information screen for some reason. Maybe I used the wrong scan codes. I remember I said I would have this ready a few weeks ago. It's more complicated than that.

Programming always is (a good rule of thumb is 90% of your time is spent debugging...)

yep, probably why I haven't completed a project in the past half year. So much debugging to do.

I can't even compile a Linux kernel without spending 26 hours (nearly) straight trying to debug it.

thats why i love python, its the reverse then (90% time coding, 10% debugging) - of course, runtime errors generating the line number and rough location on the line the error occured is extremely helpful, lolz

@Kerm: that is totally your fault tho. YOU didn't bother to read the manual

Are we going to continue work on developping BZC? Has anyone here been working on BZC on their own? Do you still come around here Snave? This topic hasn't seen that much activity recently so I thought I should restart talk on it.

Yeah, I'm still here. I've been checking back almost every day actually, but no one else was posting anything, and I had nothing to say myself; hence the silence. Currently, I'm working on some basic drawing routines in ASM: lines and rectangles. The ultimate aim here is to end up with form and control drawing routines such that Windows-like forms could be created and moved around with an arrow keys-controlled mouse cursor. I will keep everyone posted on the progress of this.

Good stuff! I'm actually working on similar routine creation for DCS6's GUIStack stuff.

Great minds think alike! I still don't understand why my test program wouldn't work. I revised the BZC code and realized that I was writing C++ code in a few places. I fixed those, compiled it, did the standard changes to the Asm code, recompiled it, and it still didn't work. I'll look around and try to find an alternative to using the Mirage libs.

Care to post up the code and exactly what's going wrong?

Didn't I send you the code? Which code do you want me to post, BZC or Assembly? Also the old problem I had before with the text is present again. The opening credits do not appear, only a bunch of garbage. I suspect it may have something to do with the parameters I pass to the drawing function and will investigate that soon. Tell me which code you want, BZC and Asm, and I'll post it.

How about both. I'd be curious to see the kind of ASM this thing generates.

Code:

I cut all the equates BZC generated in the Asm code because the majority of the code consists of equates that you don't need.

Code:

I added the Mirage header. I think I just found some possible places that are giving me trouble. Things like this:

Code:

It didn't give enough space between the memory of the sprite name and the y location, so some of the data must have been corrupted. The y location could have been overwritten or characters in the string were overwritten by the y location and other stuff. I have to remember to get that fixed soon. Also note that I had to add the MEM declarations because the compiler would give me an error with sprite names. Snave is making some of these functions without Rom Calls but I'm doing my best with my limited Asm knowledge.

.db = 1 byte reserved
.dw = 1 word = 2 bytes reserved

Exactly. The required space for an array of characters was not reserved.

/me looks at the ASM code

I love this:


Code:


Does it not trust the processor to maintain the values of the registers? There are so many Pushes and Pops, it's hard to read. At least the stack is getting a good workout. I'd advise the tried and tested method of debugging: put b_call(_getkey) after each instruction. You'll find the misbehaving one.

That said, I think I found your problem. If I am reading this correctly, you passed 7,7,89,57,1,2 to the graphlines function. As it put them into it's variables, 89 was stored to (graphlines_y2). The calculator doesn't have 89 vertical pixels if he uses the same Y axis that I'm thinking of. I tried to follow what happens after that, but I get lost in a slew of computer generated code.

Edit: Snave, why did you use a word of storage to store the graphline inputs, and then proceed to load them into single byte registers? I think that might be a HUGE problem given that the processor is little endian!

Edit2: Upon further review, it loads 89 into the correct spot. All the pushes and pops had me a little confused. I still believe the source of the error is in the storage with different data types. Let me demonstrate. Let's load HL into (x) and back into h.

Assume HL = $0015 (21 decimal for all you anti hex people)

Code:


Okay, I withdraw all of my complaints. I can find no error, but I do not have the strength to look through all of that for errors. Sorry, I can't be of any help. I think I'll leave the contents of my failure in this post so people can see both what moron I am, and how hard it is to understand computer generated code.

...and why computer-generated code is so incredibly inefficient sometimes.