A little sprite-demo (textmode)
A little sprite-demo (textmode)
Hello, Hola, Hallo,
this is my first post, and my first little program/demo for the oric.
In fact, a few weeks ago I didn't know there is something like an oric...
but I know a bit about the C64, so many things are quite familiar.
So here it is:
Well, there's not so much to see on that still image... but maybe you try it nevertheless:
spritedemo.tap
Features:
- Textmode
- Background is black/white, can use 32 chars
- 4 softscrolling sprites, 18 x 16 pixel, black/white/transparent (using 48 chars, less when overlapping)
- drawing alternating in both charsets to reduce flicker
- Sprites have an z-order and can overlapp
missing yet:
- no collision detection
- sprites can not leave (partially) the screen
- not 100% assembler, and could be optimized in speed and memory-usage
- still some flickering, obviously because I know nothing about interrupts and vsync-detection on the oric...
- technically, sprites could be 1 pixel larger in each direction (19 x 17)
If you switch the background on, you can see how the screen-update-mechanism works.
That is intended of course, could also update the whole screen at once.
Hope you like it.
And thanks to Twilighte for all the help!
this is my first post, and my first little program/demo for the oric.
In fact, a few weeks ago I didn't know there is something like an oric...
but I know a bit about the C64, so many things are quite familiar.
So here it is:
Well, there's not so much to see on that still image... but maybe you try it nevertheless:
spritedemo.tap
Features:
- Textmode
- Background is black/white, can use 32 chars
- 4 softscrolling sprites, 18 x 16 pixel, black/white/transparent (using 48 chars, less when overlapping)
- drawing alternating in both charsets to reduce flicker
- Sprites have an z-order and can overlapp
missing yet:
- no collision detection
- sprites can not leave (partially) the screen
- not 100% assembler, and could be optimized in speed and memory-usage
- still some flickering, obviously because I know nothing about interrupts and vsync-detection on the oric...
- technically, sprites could be 1 pixel larger in each direction (19 x 17)
If you switch the background on, you can see how the screen-update-mechanism works.
That is intended of course, could also update the whole screen at once.
Hope you like it.
And thanks to Twilighte for all the help!
Re: A little sprite-demo (textmode)
Great! Nice to see a new face. I'm no longer the new boy (are you using Euphoric or Oricutron for development, btw? or maybe mess?)Nox wrote:this is my first post, and my first little program/demo for the oric.
Then you already know everything there is to know about vsync detection on the oric, sadly.- still some flickering, obviously because I know nothing about interrupts and vsync-detection on the oric...
Euphoric was the de facto standard in terms of Oric emulators, but it has become more and more difficult to use on recent operating systems, and it works only on DOS compatible environments.
Recently Xeron has been working on Oricutron, a portable, next generation Oric emulator. It's still rough on the edges here and there, but it's definitely very usable, and ports of it runs on Windows, Beos, Amiga OS4 and Linux (more to come).
You can find the Oricutron project here: http://code.google.com/p/oriculator
For the development, what did you use to create your program?
Recently Xeron has been working on Oricutron, a portable, next generation Oric emulator. It's still rough on the edges here and there, but it's definitely very usable, and ports of it runs on Windows, Beos, Amiga OS4 and Linux (more to come).
You can find the Oricutron project here: http://code.google.com/p/oriculator
For the development, what did you use to create your program?
I program in Delphi on Windows.
Besides that, I only use an Editor (pspad) for C/asm and MS-Paint (yes...) for graphics.
For more advanced graphic-operations (sprite-rotation etc.) I usually write an own program/editor in Delphi.
Never managed to become friends with a "modern" graphic program, last one I mastered was DeluxePaint V on amiga
Besides that, I only use an Editor (pspad) for C/asm and MS-Paint (yes...) for graphics.
For more advanced graphic-operations (sprite-rotation etc.) I usually write an own program/editor in Delphi.
Never managed to become friends with a "modern" graphic program, last one I mastered was DeluxePaint V on amiga
I was more asking about which tools you used to do the oric program itself, is the code in BASIC, C, assembler, and if yes which C/assembler have you been using, and how did you converted the graphics to something the Oric can use.
Did you use some cross compilers/assemblers, or what it done directly on the Oric by entering lines of DATA in a basic program?
Did you use some cross compilers/assemblers, or what it done directly on the Oric by entering lines of DATA in a basic program?
- ibisum
- Wing Commander
- Posts: 1652
- Joined: Fri Apr 03, 2009 8:56 am
- Location: Vienna, Austria
- Contact:
This is brilliant, and inspiring me to do a bit of demo code too ..
But perhaps there is an interesting bug with Oricutron here? I press the 1/2/3/4 keys and not much happens - only 1 seems to turn off the box and turn it back on again - what are the other keys supposed to do? If I rapidly hit 1 2 3 4, also, the app stops and i get to the BASIC prompt .. ?
But perhaps there is an interesting bug with Oricutron here? I press the 1/2/3/4 keys and not much happens - only 1 seems to turn off the box and turn it back on again - what are the other keys supposed to do? If I rapidly hit 1 2 3 4, also, the app stops and i get to the BASIC prompt .. ?
Yes, I check the keyboard every single frame (and switch the sprites 1-4 on/off if the corresponding key is pressed).
Of course that is not a good solution for this type of switch...
will do better next time
And I use a slightly modified version from this example
http://www.defence-force.org/computing/ ... /index.htm
Had some troubles with it, but maybe it's just my keyboard
(I know that keyboards have some kind of matrix too, and cannot handle every combination of keys pressed).
So my solution was to first check the cursor-keys, and only if none is pressed I check the other ones...
Haven't explored all the tools yet...
Of course that is not a good solution for this type of switch...
will do better next time
And I use a slightly modified version from this example
http://www.defence-force.org/computing/ ... /index.htm
Had some troubles with it, but maybe it's just my keyboard
(I know that keyboards have some kind of matrix too, and cannot handle every combination of keys pressed).
So my solution was to first check the cursor-keys, and only if none is pressed I check the other ones...
Well, that makes sense, to store the images in separat files.Dbug wrote: Check the sample\c\hires_picture folder in the OSDK directory.
osdk_makedata.bat calls pictconv to generate a "picture.s" file from "picture.png".
Haven't explored all the tools yet...