Menu

#17 support for sprites?

closed
nobody
None
5
2009-12-03
2006-12-10
Anonymous
No

When I learnt programming (back then on the C64), there was a nifty thing called "sprites" (http://en.wikipedia.org/wiki/Sprite_%28computer_graphics%29), I think it would be nice to have some basic support for sprites in kidbasic, too.
Something like this could be implemented by providing an additional buffer/memory region, that users could draw to, so that they could later on reference/address this region directly and easily move a sprite across the screen.

What do you think?

Discussion

  • drblast

    drblast - 2006-12-10

    Logged In: YES
    user_id=989631
    Originator: NO

    I remember sprites, and figuring out how to do multi-color sprites on the C64 is how I learned how binary numbers worked.

    I'm undecided as to whether to add sprites in the manner that you mention (as a drawable buffer), or just to add the ability to load a .png file in as a sprite and be able to change its position, angle, etc.

    The problem I see is that sprites really were a special hardware feature of the C64, to make up for the slowness of drawing graphics with respect to the screen refresh time, which isn't a problem with Basic-256. In the case of Basic-256, there would be no discernible advantage to using sprites as opposed to a subroutine, so it might be confusing to kids. (Why did you teach me this?)

    So for that reason, I'm leaning toward the import .png image. It will add extra functionality and it's more akin to the way graphics are done today.

     
  • Nobody/Anonymous

    Logged In: NO

    agreed, the png idea actually sounds like a good and feasible compromise, in particular because one could provide transformations such as rotation by degrees in counter/clockwise direction, too

     
  • Nobody/Anonymous

    Logged In: NO

    the buffer-based idea could be easily implemented by simply adding an instruction that allows users to switch between different draw contexts, so that graphics stuff is applied to the active context/buffer

     
  • Nobody/Anonymous

    Logged In: NO

    I actually like the idea to support displaying & animating loadable images, because it would fit perfectly together with the "sound" command allowing audio files to be played-ultimately, it's exactly this sort of support that would enable kidbasic to feature interactive tutorials FOR kidbasic written IN kidbasic

     
  • Nobody/Anonymous

    Logged In: NO

    the switching buffers approach might be kinda useful as it could provide some basic foundation for more complex graphics work, i.e. in DirectX or OpenGL, where this concept is also commonly employed to prevent animated graphics from jittering.

     
  • Nobody/Anonymous

    Logged In: NO

    BTW, I think in the long run it would be neat to support most of the low-level instructions to enable contributors to enable some of the more popular arcade games ( http://en.wikipedia.org/wiki/Arcade_game ), i.e. something like tetris, asteroids, pacman or reversi.

    Given that kidbasic is supposed to be mainly used by kids, I would assume that these sorts of games IMPLEMENTED _in_ kidbasic, would be particularly appealing to kids, especially if well-commented and intuitively coded. So that kids would actually be motivated to see the potential of learning kidbasic, and seeing what can be accomplished.

    Basically, most of the required stuff is already there (i.e. graphics, sound), however it might make sense to also consider providing some support for I/O hardware such as a mouse or joystick, both of which should be possible using QT (or if necessary SDL).

    Also, given that code-reuse is a major component of programming, it might be a good idea to consider providing some sort of facility to allow code to be "pulled in", i.e. in some sort of "library"/"module"-oriented fashion. This would not only illustrate how code reuse can be facilitated, but would also encourage kidbasic users to come up with their own library of modules which may be reused in new projects. Additionally, such an effort might be accompanied by a corresponding low-level library of useful general-purpose (utility) functions.

    Of course, such a feature would remain entirely optional, and it would be up to the end users, to determine whether or not they want to make use of it.

     
  • Nobody/Anonymous

    Logged In: NO

    WRT "code reuse" and modules: supporting a "simple include/require/import" directive in the conventional way, would pose at least two new problems in kidbasic:

    1) namespace pollution: all variables in kidbasic are by default assumed to be "global", that is the chance that your code (symbol names) may conflict with module-specific stuff, is increased/very real.

    2) you cannot simply "pull in" arbitrary code at the top of your code, as this would inevitably mean, this code would be executed (usually)-that is.

    So, to address #1, you might want to implement support for LOCAL variables which use a special keyword (i.e. "local" or "var"), so that they run out of scope after the function's "return" statement:

    foo:
    local x=10; //local variable?
    ; or:
    var x=10; // local variable?
    return ; // remove local symbols from symbol table

    ...or by using some special syntax for such local variables, i.e.:

    foo:
    #x=10;
    return

    To address #2, you'll either have to explicitly "jump over" statements (to your program's entrypoint) where you include code/modules, by using a "goto", along the lines of:

    goto start
    import "mystuff.kbs"
    import "foo.kbs"
    start:
    print "hello world!"
    end

    or alternatively, provide a new "entrypoint" statement, which would have to be declared at the top of your sources, so that the interpreter can automatically determine the program's entrypoint and directly jump to it upon execution, for example:

    entrypoint start

    import "foo.kbs"

    start:
    print "Hello world!"
    end

    Concerning PNG files, personally I would find it more intuitive to provide support for basic bitmap files (bmp), simply because these are very simple to work with, and it would be directly possible to enable users to manipulate such files, or even create bmp files dynamically, i.e. by serializing a stream of bytes to a corresponding file, possibly reading out a graphics buffer, or certain screen coordinates (using getPixel() equivalents).

     
  • Nobody/Anonymous

    Logged In: NO

    platform specific I/O for stuff like joysticks and gamepads can not only be complex, but als troublesome, given that there may be new issues related to miscalibrated hardware etc.

    I would however second the idea to provide support for bitmaps, as this would mean that basic256 users may become familiar with important low-level concepts such as for example binary numbers, accompanied by some new commands for bit-level manipulations and maybe some way to express numbers differently (binary, octal, hex), DIRECTLY in kidbasic:

    x=FFh ; hex
    x=03o ; octal
    x=01010010b ; binary

    so, that most of the low-level stuff could already be easily accomplished

     
  • Nobody/Anonymous

    FWIW, there's libSDL to abstract away the differences between platforms with regards to I/O hardware like joysticks or gamepads. And I assume that Qt is offering something similar...

    -Boris

     
  • Nobody/Anonymous

    in general, it would be cool to be able to transform images, e.g. scale/resize, rotate, color depth, zoom etc.

    So having such primitives in place to be used with arbitrary images (for example in png format) would allow kids to really have a go at playing around with it.

    At some point one could even add support for capturing photo/video via webcams, so that kids could interact with their own webcam, which would be very much like LEGO!

     
  • Nobody/Anonymous

    Using bitmap files would also have the advantage that it is made very simple to directly turn them into AVI videos, so that people could at some point turn animations into videos if desired and save/replay them, possibly inside the graphics area of kidbasic.

     
  • Jim Reneau

    Jim Reneau - 2009-12-03

    I have done much research into adding sprites to BASIC256 and do not have the time to do it now.

    As a compromise measure (and a really cool feature) the STAMP graphics command has been added. STAMP takes a polygon definition and relocates, scales, and/or rotates it. This should allow for a much simplified moving object on the screen. It still doesn't do layers but this should be a first step. It was added with 0.9.4 on 12-03-2009

     
  • Jim Reneau

    Jim Reneau - 2009-12-03
    • status: open --> closed
     

Log in to post a comment.