#170076 - ArugulaZ - Fri Aug 28, 2009 3:12 am
I'm thrilled with the progress I've made with GORF! All five stages are included now, along with some sound effects and collision detection for the player's ship. I'd put it at 75% finished now. Download the alpha from my web site and let me know what you think of it... what you liked and what could be improved. Who says you can't do anything with BASIC? :D
http://www.lakupo.com/grblitz
#170078 - dantheman - Fri Aug 28, 2009 4:51 am
Not bad at all. I'm very impressed with what you've managed to make with DragonBASIC, considering its relatively high overhead. My only criticism is with the way bullets are fired, as I'm used to just hitting the fire button often rather than having to wait until it hits. Looking at the top of the source file though, it looks like that's already on your to-do list, which I'm glad to see.
EDIT: fixed horrible late-night grammar.
Last edited by dantheman on Fri Aug 28, 2009 6:24 pm; edited 2 times in total
#170083 - ScottLininger - Fri Aug 28, 2009 5:07 pm
Fantastic! Nice gameplay, consistent look & feel, and a complete thought!
Well done,
Scott
_________________
Some of my GBA projects
#170093 - ArugulaZ - Sun Aug 30, 2009 12:22 am
Thanks guys, I appreciate the encouragement. This has been a labor of love for me... if you've ever played the other home versions of GORF, you'd understand why. I still get nightmares from the ColecoVision game... brr!
#170134 - keldon - Tue Sep 01, 2009 5:17 pm
That is excellent. You don't have to be great to complete a your work, but you have to complete your work to be great!!!
Bravo ... only wish I hadn't destroyed my EZ flash cart :'(
#170142 - ritz - Thu Sep 03, 2009 2:50 pm
Very good game, very well done!
| ArugulaZ wrote: |
| http://www.lakupo.com/grblitz |
P.S. Awesome slogan on your webpage: "For the love of the game". Wish I would've thought of that... you should make it your sig :) Or, maybe, you could quickly delete it before people read this and *I* can use it ;)
#170162 - ArugulaZ - Fri Sep 04, 2009 9:06 pm
Glad you're still following this project! It's grown by leaps and bounds since the last time I posted. You can download the latest beta from my web site:
http://www.lakupo.com/grblitz
The core game is pretty much finished at this point, and there are a variety of extras, including an art gallery and a title screen. I'm amazed at just how good Dragon BASIC is... after registering the product I haven't bumped into any restrictions or limitations, and my game is pushing 7000 lines at this point. BASIC or not, this could easily be used to make professional-quality games. It's just a shame that there isn't a DS version of the software... I would have loved to see what Massung could have done with the hardware. He's working for Disney or something now, correct?
Anyway, thanks for the encouragement! I'll keep plugging away at this and keep you posted on its progress!
#170167 - Dwedit - Sat Sep 05, 2009 1:56 am
I don't know if you can do anything about it, but it always uses 100% CPU usage without halting, making it a battery eater. (NO$GBA debug version tells you those things immediately)
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#170174 - ArugulaZ - Sat Sep 05, 2009 5:33 pm
That explains why it chews through my Game Boy Micro's battery in an hour. It's like playing a friggin' Atari Lynx or something.
Honestly, I don't know if I can do anything about this, but I do appreciate the explanation.
#170177 - Dwedit - Sat Sep 05, 2009 7:17 pm
In order to wait for Vblank, Dragon basic is doing retarded stuff like this endless loop which repeatedly checks what the current scanline number is:
mov r2,#0x04000000
0:
ldrh r3,[r2,#6]
cmp r3,#160
bne 0b
Which is a big NO-NO for how to wait for vblank. The proper way is to install an IRQ handler, then use SWI WaitForVblank so the system can enter low power mode.
It might be possible to ASM hack the game to make it not do that.
Don't feel too bad, even commercial games like Wario Ware even have bad Vblank wait code.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#170179 - gauauu - Sat Sep 05, 2009 11:15 pm
| Dwedit wrote: |
| (NO$GBA debug version tells you those things immediately) |
Rub it in, why don't you ;-)
Alas, what I wouldn't give for a copy of that thing.
#170180 - ArugulaZ - Sun Sep 06, 2009 12:25 am
There is a dedicated VBLANK command in Dragon BASIC that might solve the problem, but it seems to slow execution time. I believe the loops in some of the stages may take two vertical scans to complete, and when you add a pause for vertical blank on top of that... well, things start to crawl. I'll experiment and see if I can fix the problem without hurting the gameplay. I really hate the hit it takes on battery life, and anything that can address this would be appreciated.
#170288 - ArugulaZ - Wed Sep 16, 2009 12:50 am
Here's the nearly finished beta of GORF. Please give it a spin and let me know what you think of it.
http://www.lakupo.com/grblitz/gorf_beta_98.zip
#170291 - Dwedit - Wed Sep 16, 2009 4:29 am
Okay, I'll go look at the "Dragon Basic" language and see if there is any way I can make it less retarded and less battery munching.
Edit: I successfully modified the libraries, and made the minesweeper example program use the proper way to wait for vblank.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#170292 - ArugulaZ - Wed Sep 16, 2009 6:05 am
Really? Hmm... maybe I'll try feeding my GORF code into the modified version of Dragon BASIC. Worst it could do is give me an error, right? Do you have a ZIP file of the revised compiler and libraries?
#170302 - Dwedit - Wed Sep 16, 2009 1:23 pm
Add this code somewhere in Interrupts.f:
| Code: |
\ wait for an interrupt
: waitirq ( -- ) 02 swi ;
|
and inside interrupts.dbc:
| Code: |
PROTOTYPE SUB WAITIRQ
|
Add this to core.f:
| Code: |
\ wait for the next vertical blank
code vblank2 ( -- )
$4000000 ## v0 mov,
\ wait for vertical blank
l: __wait
2 swi,
v0 6 #( v1 ldrh,
160 ## v1 cmp,
__wait ne? b,
\ done
ret
end-code
|
Add this to core.dbc:
| Code: |
PROTOTYPE SUB VBLANK2
|
Then an example of how to use the new code:
| Code: |
DIM needtowait
SUB VBLANKWAIT
If needtowait = 1
VBLANK2
END IF
needtowait = 1
END SUB
vbl: SUB NONEEDTOWAIT
needtowait = 0
end sub
; Entry point
start:
;You must install the IRQ handler and enable interrupts, otherwise the vblank wait code will crash.
needtowait = 1
ENABLEINTERRUPTS
ONVBLANK vbl
|
Then any time you want to wait for vblank, call VBLANKWAIT. It uses the needtowait variable to prevent it from waiting two frames if your code got too slow. You can also set needtowait to 1 to force it to wait, or just call VBLANK2.
I'm not 100% sure if the needtowait stuff actually works or not. I think it does.
The built in VBLANK function is bad. Never call it for any reason. It lacks any code to enter low power mode.
If you want to do it for timers, you would add an ONTIMER, and a timer handler, then enable interrupts for the timer, then call WAITIRQ when you want to wait for the timer to finish (you only do this if the timer is not already finished)
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#170308 - ArugulaZ - Wed Sep 16, 2009 3:13 pm
It seems to work great! It slowed my production logo to a crawl, but everything else works at the speed it did previously. I'm going to test it on the actual hardware in an hour after my GameBoy Micro is fully charged, and return with a report shortly afterward.
Thanks, by the way!
Oh yeah, one question. Dragon BASIC officially supports four rotation matrices, but will allow more if you assign them. Could this have something to do with the logo running more slowly than the rest of the program? I've got a ton of rotation going on there, what with the letters squashing and stretching and all.
#170309 - Dwedit - Wed Sep 16, 2009 3:20 pm
Rotating and scaling sprites is free, the hardware does that for you. Calling matrix muliplication code is not free though.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#170320 - Miked0801 - Wed Sep 16, 2009 6:16 pm
But not too bad to do - depending on the implementation. Even a 3x3 X 3x3 matrix mul is only around 18 muls and adds. Child's play if done right in code.
#170334 - ArugulaZ - Thu Sep 17, 2009 5:10 am
(sigh)
I'm hearing reports that the game has a grudge against 3-in-1 cartridges. Evidently it's a header problem, but I can't test it for myself because I don't have one of these cartridges, and I can't really fix it because I don't know ASM. I wish I didn't have to ask, but I'm going to swallow my pride and do it anyway for the sake of the game. Can anyone help?
#170340 - Dwedit - Thu Sep 17, 2009 1:34 pm
You don't need to know ASM to fix a header problem, you just need to whip out a hex editor, and fix it.
But knowing HOW to fix it is the problem. Find someone who knows about hacking games to work with crappy flash products.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#170348 - ArugulaZ - Fri Sep 18, 2009 2:22 am
I forgot I had a tool called GBAfix. Never used it in the past because hey, it worked with my card! I just forgot about everyone else's...
#170427 - ArugulaZ - Wed Sep 23, 2009 3:53 pm
All right gang, the game is finished. I might do some bugfixes and touch up the Mission Matrix a bit at a later date, but for the moment, I'm done. You can get the finished product from this address:
http://www.lakupo.com/grblitz
I was hoping for a more enthusiastic response to the game, but so far it's been pretty tepid. My dreams of fame and fortune have been dashed! ;)