Vectrex sprite hacks (don't exist?)

[gliptitude]

I was wondering if it would be difficult to do or what it would involve to edit the graphics of existing GCE vectrex games and recompile a new ROM with these graphics. Seems common on NES games (such as super afro brothers), but I've never seen a hacked vectrex game. Does it exist? Is this as simple as editing a single section of the program, redefining the y,x coordinates? Are the "disassembled" vectrex roms out there actually complete programs that can be edited and compiled?

[woodentulip]

The Copyright Date and some Text elements can be replaced in Rom Images in HexEdit formatted editting. (I played with this with VecXGL I compiled; and games I run under that EMU. I editted the ROM images using XVI32)

If the Game has been well disassembled, and documented; You can edit the Vector setups of certain types of elements in a given game.

But why do that? Its actually easier overall to sit down and code with the AS09 assembler and code for a Vectrex Game and build your own ROM image and then play that.

As you have said, with Sprite-based raster game systems, this is pretty much a capable "resource editor" type of find/replace.

In Vector-based systems, you need to know the object setup for the Vector element, as well as it's timings to draw it. -- And that is the art of doing Vector-based elements. One wrong setup and the timing for a nice game is completely wrecked.

-s

[gliptitude]

Hey thanks for replying to this thread. Also, I see you are a new member. Welcome!

Nov 1, 2012 20:44:36 GMT -5 woodentulip said:

As you have said, with Sprite-based raster game systems, this is pretty much a capable "resource editor" type of find/replace.

In Vector-based systems, you need to know the object setup for the Vector element, as well as it's timings to draw it. -- And that is the art of doing Vector-based elements. One wrong setup and the timing for a nice game is completely wrecked.

-s

I wonder if you can explain this further and also if others can confirm this.

The reason I would want to edit "sprites" rather than code a new game, is that I have no programming experience and I don't know where to start. I would be extremely excited to see the concrete results with graphics hacks. Also I think the process of analyzing an existing program, and culling the sprite elements, would help me to understand what a program consists of, and how it is structured.

I don't understand how starting from scratch would be easier than graphics hacks, when there is much more to a game program than graphics.

[woodentulip]

I can Glip.

Unlike NES or SNES-based Sprite games. Or GB / GBA Games. The Vectrex uses Vector objects.

Take Spinball for example. The Vectrex is pretty much drawing the same thing over-and over.
The trouble with Spinball is the math for the Gravity of the ball. It takes so much time to calc the math, that the Screen is VERY flickery.

(Gravity is not so much the problem as opposed to calculating the vector equation for the balls trajectory, and then calculating collision detection, and getting the button presses / joystick interface from the Mux.)

For what appears to be graphically simple, the game is complex, and the screen vector refresh is the best that can be gotten away with. Change it, and watch at it falls down completely.

A great tutorial on Vectrex Coding is from Christopher Tumber. His writeup on developing V-Frog*er as well as the source code comments gives a wonderful explanation.

Here is Chris'es tutorial: www.playvectrex.com/designit/christumber/tutorial.htm

And here is the commentary on PROGGER.TXT
vectrexmuseum.com/share/coder/DIS/CHRIS/VFROGGER/SOURCE/PROGGER.TXT

This in a nutshell is what you need to get up to speed upon.

For me, I could say the Vectrex is a developers nightmare. (Sooo much to keep aware of!)
But then again. "REAL PROGRAMMERS" don't code in Pascal either.

-sean

[gliptitude]

Sean, I read this second reply of yours back when you wrote it. At that time I pretty much accepted confirmation that what I was contemplating doing was not simple and not a reasonable place for me to start. ... I didn't view your Tumber links back then because I had already viewed his tutorial in the past and I knew that it was very difficult for me to grasp.

But yesterday when I revisited your post, I checked out your other link, commentary on VFrogger. ... Also recently I tested someone else's Vectrex game demo on my Vectrex, at a point when he had only ever seen it on an emulator. (I saw for myself that it displayed cleanly and routinely on the emulator, but was somewhat of a mess on an actual Vectrex.) I think both of these experiences have made what you have said more clear and apparent to me.

I was previously just a little bit defensive about this idea of 'sprite hacking', because I know that people get caught up on the term, that it literally means 'an array of pixels', and there are no pixels in a vector object. But vector objects still have a defined identity in the program, and 'sprite' is the most convenient term for such graphics items.

It still seems to me that technically it is the case, that vector 'sprites' may be altered, but that basically the entire existing program depends very particularly on the original graphics, that every Vectrex program involves a process of coordinating all of the game elements, in order to display properly.

I guess in the case of raster games the issues of 'display' are much more routine? A console like NES has a regimented number of pixels (resolution), and a regimented number of color choices each pixel may be? The amount of program data devoted to the graphics at any moment in any game is relatively consistent across the platform?

Meanwhile, with Vectrex there is a more open and direct negotiation with the display hardware. There are things that can be done in some situations that can't be done in other situations, and the range of the various things that are done with Vectrex graphics varies much more than the raster counterparts. ???