Tuesday, 02 December 2008
 
  Home arrow Forum  
Main Menu
Home
News
Forum
Documentation
Download
Links
Administrator
Login Form
Welcome, Guest. Please login or register.
December 02, 2008, 08:26:29 AM
Username: Password:
Login with username, password and session length

Forgot your password?
Ship vs. Target
DSLua Community
Welcome, Guest. Please login or register.
December 02, 2008, 08:26:29 AM
1723 Posts in 315 Topics by 6333 Members
Latest Member: kneemiage
DSLua Community  |  DSLua - Best scripting language for Nintendo DS  |  Home-brew/Hacks/Games/Projects  |  Ship vs. Target « previous next »
Pages: [1]
Author Topic: Ship vs. Target  (Read 978 times)
sylus101
Waxing Crescent
**
Posts: 74



« on: September 03, 2007, 10:09:11 PM »

Hello everyone, it's been awhile.

This was more a test project to tackle a problem I wasn't sure on how to approach, so please don't consider this an actual finished "game." The dilemma was, how to move several sprites at once, independently, without interfering with one another. I could move one, but another might stop during that movement because of pauses that made the movement more smooth, etc...

My first attempt was good. I set up a counter system so that things moved at a normal rate but there was never a need to call a waitforvblank or other kind of pause or delay.

The problem that came up after that, was that the more Sprites that moved at once... the slower DSLua went and all the sprites slowed down...

The final solution was to always have the same number of sprites moving at any one time. If the ship isn't moving, an off screen sprite is. If you fire the blaster, another starts up. As the controlled sprites move, the off screen sprites stop. It works quite well as far as I can see.

This is nothing fancy at all, just more of a proof of concept, so to speak. Move around with dpad, press A to fire. I was about to add that crashing the ship into the target did something, but stopped to move onto bigger and better things... now that I know this works.

shipvstarget.zip

Play it in 0.6, I really don't think 0.7 is working quite right. Most of the sprites I work with load up funny in 0.7.

BTW... I don't presume to have broken some kind of magical barrier as I'm sure this has come up before. Anyway, I was glad to find a way to do what I wanted and I hope others can benefit from it as well.

-Sylus
« Last Edit: September 04, 2007, 02:39:18 PM by sylus101 » Logged
sylus101
Waxing Crescent
**
Posts: 74



« Reply #1 on: October 18, 2007, 11:53:22 AM »

Okay... well I'm not a moron, but I'm gathering I fell into a classic blunder of types.

The method I'd come up with before in this ship vs. target demo worked, but it was a method entirely void of DSLuaWaitForVBlank() entries. I had believed I needed to do that, because I didn't want the movement of one sprite to interfere with another.

In the new project I'm working on, I set up a similar system with counters and actions based on the value of the counter.

Something might happen with counter1 == 100 then when counter1 == 400 etc...
The problem, is that I had to adjust those counters the more I added, and that began to get more than a little annoying.
While researching a little on PALib (sorry guys... really looking for more sprite manipulation as time goes on... but will likely stick with DSLua for awhile longer) I noticed in a tutorial the addition of the WaitForVBlank() (it was PAWaitForVBLank instead of DSLua)  and a note that it was necessary to keep the screen going at 60 frames per second. I knew this but the idea I'd had involved some loading and unloading of sprites and need a delay that I had thought the waitforvblank would screw up. With a fresh look, I found I was basically dead wrong.

Anyway, the issues with ship vs. target where I'd added extra sprites to move and not move to retain the speed of the program have become totally unnecessary. With one friggin DSLuaWaitForVBlank() in the main while loop, several sprites (still moving based on increasing counters) can move without slowing each other down and the program has not slowed down at all. Instead of counters reaching the hundreds before actions happen, it's more like at 1 or 2.

Now the only issue I'm seeing I'm bound to run into, is if I need to move something faster than 1/60th of a second...

Live and learn I suppose...
« Last Edit: October 18, 2007, 01:54:37 PM by sylus101 » Logged
Pages: [1]
« previous next »
    Jump to:  



    (C) 2008 DSLua

    DSLua - Best scripting language for Nintendo DS home-brew!