This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Quigibo
Pages: 1 ... 102 103 [104] 105 106 ... 135
1546
« on: May 10, 2010, 02:06:44 pm »
If you make a 15MHz-only game, it wouldn't be compatible on the regular 83+ anyway, so there would be no reason to make separate versions. Otherwise, you would just use the 6MHz gray for both.
1547
« on: May 10, 2010, 01:58:35 pm »
I'm talking about the draw routine itself, the DispGraphr routine.
I think I will use separate routines for each speed. You'll basically never use both of them in the same program anyway, so it can only save size and speed.
1548
« on: May 10, 2010, 05:04:53 am »
I'm having a little grayscale crisis.
First of all, it needs to have constant pause times or else it looks really crappy so I can't use the screen delay timer. If I make the pauses short enough, its speedy fast for 6MHz mode but fails on 15MHz mode. If its too long, it looks great on 15MHz mode, but really lags in 6MHz mode. That means, it has to pause a different amount of time depending on if its in 6MHz mode or 15MHz mode. I can add a check to pause a different amount of time for each mode. The check is too much code to look good on 6MHz mode unless I fix a few things. If I use some undocumented instructions, I can speed it up fast enough to look good, but then I lose compatibility with the NSpire. I could also skip one of the checks to speed it up, but then it still pauses the longer 15MHz pause time when using a regular 83+ thus losing compatibility with the original 83+.
So it seems like a lose-lose-lose situation right now. I can't seem to find a way to make the routine fast enough yet still compatible with every model at every speed. I might have to either make separate routines for each speed or just settle with the ugly "checkered" grayscale. I don't know what to do.
And don't say I'm being too picky about quality. If perfect gray is not reproducible, it defeats the purpose of the command since then you might as well just flash the images on and off since that flickering would be less annoying than the checkered flickering.
1549
« on: May 10, 2010, 04:47:50 am »
Axe Parser
Beta 0.2.3
New Features:- Clear the back-buffer
- Invert the back-buffer
- Copy data from end backwards
- Logical boolean operators
Changed:- Logical operators are separated from the previous bitwise operations.
- Grayscale is once again a 6MHz-only command until I resolve a compatibility issue.
- Exact percent should show up on errors.
1550
« on: May 10, 2010, 03:09:50 am »
That's impossible becasue the name has to be exactly 8 characters. I could replace those spaces with null characters instead, maybe that will fix it. Tell me if it works in the next version.
1551
« on: May 10, 2010, 02:24:34 am »
Is anyone else getting this error?
Could it be possible your high score code is leaking and overwriting the program size bytes? Like I'm confused where that "S" is coming from when you first check if the high score file exists. I never saw S initialized. Also, could it be possible you're using a ram location used by MOS like L2?
1552
« on: May 10, 2010, 02:12:03 am »
Yeah, that division will work as long as HL is in the range 0 - 4095. You didn't post a range earlier so I was unsure if the problem you were getting was becasue you were outside this range. Here, try this:
LD HL,(Score)
INC HL
LD (Score),HL
ADD HL,HL
ADD HL,HL
ADD HL,HL
ADD HL,HL
LD A,63
SUB H
LD (ScoreMeter),A
I am assuming ScoreMeter is a one byte variable here since it should only hold values between 0-64 correct? Which also means you should never load it into HL directly anywhere in your code. If you need it in HL at some point, you have to do this:
LD A,(ScoreMeter)
LD H,0
LD L,A
I suspect this might be the problem part.
1553
« on: May 10, 2010, 12:57:53 am »
Actually, you can detect collisions every other frame (as long as things are moving slow enough) for the best speed increase without changing anything else. You can use that Z=0 trick for that too.
Don't feel like you have to have to follow all the advice everybody has offered so far. Some of it is redundant, like you wouldn't want to move by 2 pixels AND update every other frame, becasue that would be 4 pixels per frame, way too fast. And doing calculations twice before updating is the same thing as updating every other frame. Just go for simplicity. There's many many ways to increase speed.
1554
« on: May 10, 2010, 12:50:51 am »
Honestly, I don't really care how big the source is (within reason) since it will generally be smaller than the executable and it can be archived during parsing. You would never have a 10000 byte source since the compiled program would likely be around the 16kb limit anyway.
Also, I do have finals coming up soon. Don't expect much over the next month. I'll still try to update every week, but there'll probably just be 2 or 3 new things in each version from now on until school ends. Once summer hits, there will be rapid progress again and 1.0.0 will be finished before the end of summer.
1555
« on: May 10, 2010, 12:39:42 am »
updating the screen would. calculating takes very little time, its just mainly conditionals "if M=1:O+1-->O:End"
Not true, when you're checking collisions of multiple enemies with multiple bullets, it really strains the calc for speed, that's why you noticed slowdowns in the first version when there were more ships. Even the sprite drawing calculations become negligible compared to the collision detection.
1556
« on: May 09, 2010, 12:35:04 pm »
Nah, I don't think popularity of BASIC or asm will go down. You still need asm to make really large games and things that require even more speed. And BASIC still has advantages like floating point numbers and it is still easier than Axe since it doesn't need pointers. You can't make a math program on Axe nor can you make a 3D raycaster (yet).
1557
« on: May 09, 2010, 12:30:27 pm »
I would recommend getting used to it becasue one of my future plans include variable aliases, which is a way to name variables like instead of S, you can call it "Score" but all letters after the first one have to be lowercase to avoid ambiguity.
Or you can be like me and just keep it off by default and only turn it on when you need a lowercase character.
1558
« on: May 09, 2010, 12:17:54 pm »
"Score" and "score" are not the same variable right? Because you when you inc the score, you're only inc-ing the low byte. So if your score was 255, then the inc would make it zero again. Do this instead:
LD HL, (Score)
INC HL
LD (Score),HL
And then the score is already in HL for the rest of it. On the other hand, if your score is a 1 byte variable, you never want to load it into HL directly becasue the high byte will be random. Do this instead:
LD A, (Score)
INC A
LD (Score), A
LD H,0
LD L,A
Also, when you do those add hl,hl that multiples it by 2, it doesn't divide by 2. If you want to divide by 2, you can do a bunch of these instead:
SRL H
RR L
This divides HL by 2.
1559
« on: May 09, 2010, 12:07:34 pm »
How would you connect it? To a computer serial port maybe? One thing that can be done is to have a program on the computer do most of the work for you and only send to the calc a compressed web page instead of html, that would make it significantly faster. You still navigate the web on the calc, but the data you send back and forth is easier, and less of it.
1560
« on: May 09, 2010, 12:00:51 pm »
Find a variable you aren't using and try this:
If Z=0->Z
<Sprite drawing>
DispGraph
End
It will only render the sprites every other frame yet all the movement is done every frame so it appears to be twice as fast.
I lol'ed at the lobsters by the way! This looks nice so far.
Pages: 1 ... 102 103 [104] 105 106 ... 135
|
Show Posts