|
|
Post by christophertumber on Oct 20, 2014 22:09:35 GMT -5
This is not a new project! Because I'm not starting new projects until WIPs are done... Incursion currently doesn't support any enemy sprites. Specter does, but the routines are highly specialized (grid based). I decided I needed to write some good, optimized sprite handling routines I would use for Incursion and possibly other games - Hardware based sprites on retro-systems are a fantastic resource while later libraries often include all kinds of sprite handling support. If I can build a nice, modular (so I can drop unnecessary pieces), sprite display and handling kernal that would be extremely useful for future projects. Especially if optimized enough that I don't need to keep reinventing the wheel There will probably still be a little of that inevitably depending on exact usage but a solid framework is a great start. So rather than develop this inside the existing Incursion source code, for a variety of reasons (clarity, avoidance of possible conflicts, ROM size) I did this as it's own source code. In developing this engine, I had to throw it some test shapes. This is the result, and in testing it I realized, "Hey, this is basically a long way towards an arena shooter like Robotron or Geometry Wars". So here we are. Two binaries with slightly different enemy shapes and configurations. Enemy movement is pretty basic but it can display up to 50 sprites (including the player) plus the player's shots. Currently running at 40fps which looks pretty good on real hardware.   |
|
|
|
Post by cNp on Oct 21, 2014 4:35:15 GMT -5
Well that's an insane amount of sprites on the screen, kudos!
cNp
|
|
|
|
Post by gliptitude on Oct 21, 2014 14:27:33 GMT -5
Wow that looks really cool! ... and actually those don't just look like thrown in test shapes to me. Cool design and style in my opinion. (I'm just looking at the pics, don't have access to the files or vectrex at the moment).
.. Can you explain to a layman what "hardware based sprites" are? .. I thought you might mean there is extra components on the cartridge, but if it is all contained in a .BIN that can play on real hardware with a flash cart then I definitely do not understand.
|
|
|
|
Post by christophertumber on Oct 21, 2014 15:42:57 GMT -5
.. Can you explain to a layman what "hardware based sprites" are? .. I thought you might mean there is extra components on the cartridge, but if it is all contained in a .BIN that can play on real hardware with a flash cart then I definitely do not understand. The Commodore 64 and NES, for example have hardware based sprites. You set some registers and push some data into specific RAM and the hardware handles all the heavy lifting as far as drawing (those objects - usually foreground objects like the player and enemies) to the screen. And will continue to do so until those registers/RAM are changed - Every subsequent frame there is no CPU time required to display the sprite as there's dedicated hardware (a component of the video chip). So you only need to update when changes are made and when you do it's just a matter of changing a little bit of data. Some include hardware based collision detection which is a huge asset because collision detection can take a lot of time (ie; comparing 50 objects with the other 49 objects for a total of 1225 compares [there are ways to optimize this so you don't do nearly so many compares - usually by dividing the screen into quadrants and not bothering to compare sprites in different areas of the screen but still you can see this is potentially a lot of time spent checking collisions]). On raster systems that do not have hardware sprites (ie; Commodore VIC-20), this usually means using (redefined) character graphics which is generally not nearly as fast/convenient as sprites (smooth movement is much more difficult) but is still hardware based. Once you setup a screen, the hardware will keep displaying it for you, you just need to make changes. On the Vectrex, or anything else without any of this capability you need to manually draw sprites to the screen in real time. The Atari 2600 despite being a raster display is similar since it has no video RAM. The display in an Atari 2600 needs to be drawn in real time as well. What I'm trying to do is create a set of routines that operate similarly to hardware sprites, that are fast enough and general purpose enough that I can keep reusing them (as opposed to reinventing the wheel each game) and will give good performance though they'll never be as efficient as true hardware sprites. Long and short of it - In most cases, a Vectrex game spends 80%+ of it's CPU time drawing the screen. Most raster displays spend maybe 10% (unless they're doing something really sophisticated like a bunch of raster interrupts). And the "routines" to do so are built in and execute automatically. You don't need to create your own. This means you run out of time on the Vectrex if you want to draw really complex scenes. And you generally have a lot less time available for non-drawing tasks like AI or 3D calculations &etc. Here's a metaphor - Most raster based systems are movies. Once it's on film, you're done. It can be played back at any moment, millions of time. The Vectrex is a play. In order to give a performance, you need live actors working in real time. The CPU in the Vectrex is actually about 50% faster than the one in the Commodore 64 but the VIC-II video chip in the Commodore 64 does a lot of the heavy lifting so the average C64 screen has way more complexity than the average Vectrex screen. |
|
|
|
Post by christophertumber on Oct 21, 2014 22:05:28 GMT -5
Emulator (MAME) videos:
|
|
|
|
Post by VECTREXER on Oct 23, 2014 13:57:41 GMT -5
So what might be good is a documented method to add in faster / overclocked CPUs into a standard Vectrex. Along with a method to return the clock to normal, or underclock a faster CPU, as needed. Along with the RAM as needed.
Perhaps an FPGA as a full replacement for the CPU and RAM overclocked as much as possible.
|
|
alx
Vector Runner
Posts: 10 
|
Post by alx on Oct 24, 2014 2:29:32 GMT -5
Or use an Hitachi 6309 (pin compatible to the 6809 but if switched on most operands are faster and there a new registers and operations). As for RAM: the MuCaREX (Cartridge) adds 16 KiB RAM at $8000-$bfff. (We're currently working on a new version of it). |
|
|
|
Post by gliptitude on Oct 24, 2014 13:43:36 GMT -5
When i first read this thread i was very curious to see the program running on Vectrex.
Now i've tried it out and taken some video of it. Is there any conflict with me posting it on youtube?
|
|
|
|
Post by christophertumber on Oct 24, 2014 14:21:43 GMT -5
Now i've tried it out and taken some video of it. Is there any conflict with me posting it on youtube? Please go ahead. No worries. |
|
|
|
Post by gliptitude on Oct 24, 2014 14:37:18 GMT -5
|
|
|
|
Post by christophertumber on Dec 7, 2014 21:53:35 GMT -5
For anyone not following the most wanted ports thread in the main Vectrex forum, here's the current state of the player's ship. - Joystick is analog - 64 directions - Positioning of joystick determines speed - Button 4 shoots - Button 3 fixes the ship's position. Use this to rotate in place or dash type movement by pressing and releasing the button while the joystick is in position Test on real hardware or an emulator which supports analog joystick (mouse control on ParaJVE works ok). Attachments:64sprites.bin (3.48 KB)
|
|
|
|
Post by gliptitude on Apr 17, 2015 13:45:14 GMT -5
I got a chance to test it. Will comment in the analog digital thread.
|
|
|
|
Post by garryg on Apr 20, 2015 16:20:57 GMT -5
Don't suppose there's any chance of you posting the assembly?
You could make a Vectrex bullet hell shooter with this code.
How does it run with text on the screen?
|
|
|
|
Post by christophertumber on Apr 21, 2015 13:38:59 GMT -5
|
|
|
|
Post by garryg on Apr 21, 2015 19:31:57 GMT -5
Yeh... um ... I meant Bullet Hell as in pattern-shot based vertical or horizontal scrolling SHMUP.
It would be good if you could also show a redefined character-block based 'boss' on the screen, or use redefined characters as a scrolling background, but I assume this would instantly produce way too much flicker.
|
|
