VIDE Feature Requests

Surprise of all surprises! RunnerPack has suggestions for something!? Get outta town! 😉

1. I second DogP’s idea and add that maybe some simple cropping and other adjustments might be possible before the import happens, too.

2. Speaking of the Map Builder, why do I have to add a blank Charset to the project before I can use it?

3. Also, red is fine and dandy, but how about color selection for each of the shades displayed in the editors? If nothing else, it would allow tweaking the gamma ramp of the red shades to simulate in-game BRT effects.

4. How about letting us resize the Project Scheme/Message log window so we can ACTUALLY READ THEM?! 😉

5. Open source the main program and plugins.

6. “Remove clones” functions that don’t break maps using the charset. It doesn’t have to adjust the map automatically, just make the clone chars black or put an “X” in them or something.

7. Maybe incorporate emulator frontend style options for running the new ROM? (Plugin-able to allow for new/changed emus?)

8. Full-screen preview?

9. Everything that has options (emu options, palette colors, editor fonts, etc.) should have a combo-box to store and retrieve favorite settings quickly. See the Goldwave sound editor for an example.

10. Configurable hot-keys for all menu items and toolbar buttons.

That should be enough to get you started 😉

BTW, welcome back to the scene, Alberto! 😀

(There goes my last shred of hope for 3rd place ;-))

Thank you guys for all your support. All ideas are welcome. This new VIDE version as Chris comments should mix the best of both worlds, the programming (meaning source code) and media resources (meaning images, music and so on). Developing TRON, I faced many problems with ViDE, starting with the gcc compiler support, the native support for many external tools and even some bugs (like the 64k restriction in text editor).
Finally, ViDE for TRON meant just a MAP, CHARSET exporter instead of a unified environment for VB development. It compiles using a BAT file instead of using ViDE, Imagine that!
The goal would be to build from scratch a new version even as open source or a VS template… Im not sure, but definitely it needs “reengineering” 😀
Hoping to read as many ideas as possible, have a great day.
Alberto

I’ve just recently started programming, but one thing that I think would be nice would be the ability to zoom in on Charmaps, so that you could more easily select the tile you want.

Hi,
Just to let you know I tried to figure out how to do the less work, but finally I decided to start from scratch.
I will use C# and .NET Framework to made the code as easy as possible. The VIDE will work as follows:
1. It will take a “environment” descriptor written in XML to tell the application what kind of resources it should read and which plugins will be loaded. So VIDE will be a plugin/resource manager…
2. The application will instance the plugin
3. The plugin will have its own descriptor in XML to know the messages to send or receive (read below)
4. Both App and plugin will share a common procedure called “control” that will be the communication pipeline
5. According to their descriptors, messages will be available to interact even with other plugins
6. Each plugin knows how to behave so could be resource compilers, displays, morphers, and even virtual processors, memories and IO devices to attach an emulator if desired

The following diagram explains this idea:

Finally, all plugins and application will share a common package called VIDE with a toolkit of functions to share.
Thats my idea. 😀 Let me know your comments.

You are right, this architecture will bring us many possibilities, if someone wants to debug the graphics, the sound, even on real time execution, memory extraction, etc… great plugins *libraries will bring a great VIDE.

jorgeche wrote:

[…]

If there is a plugin which does not optimization, but just map each 8×8 pixel matrix to a char it would be great!.

jorgeche

This can be done with grit using the -mR! option (map Reduction: none). You can also individually turn off clone and flip-clone reduction (as well as palette reduction, although it doesn’t really apply to the VB).

I just thought of something:

grit could be modified to output to and accept input from a VIDE project file. Then, we’d have the best of both makefile incorporation and GUI editing.

(RunnerPack makes a mental note for after the compo ;-))

Why not just make an image with all your frames (like zub_frames_vb.gif), convert to a BG map and chars, and control which frame is displayed by simply changing the offset into the BG?

Right now I have 30 frames of animation for Mario in my demo, and I have maybe 20 or so more frames to import. Each animation frame uses 20 chars, thats 600 chars, let assume that it is half that number if I use the char optimizations that Vide does, they are still 300 chars, which will consume more than half a char segment, so it is not that good.

If you take a close look to tile base sprite engines, they use various techniques to allocate different characters bases on how many animation frames they have.

The way you propose is applied in my engine but for simple characters like koopa or the piranha plant (take a look at the bgmap memory).

If you look the char memory in Wario, you will notice that the chars for Wario are rewritten each time that a new animation frame is shown, so I took the idea from it.

jorgeche

I see this topic is still a sticky, but pretty old… any word on the progress of the new VIDE? I don’t have any new suggestions, but reading through this post again makes me excited about how cool it will (hopefully) be.

DogP