Original Post

I have been talking to Alberto Covarrubias, author of Virtual-E, VIDE and other cool stuff. Thanks to the FlashBoy, he is back to the scene and plans to release an updated version of his development tool “Virtual-Environment” aka VIDE.

Ideas for now are:
* Better compiler integration (to act as gccVB frontend)
* FlashBoy loader integration
* Sound editor(!)

In this thread, we would like to gather some feedback from developers, and collect ideas for new features and improvements. πŸ™‚

22 Replies

I’d like an adjustable threshold for the map constructor… basically if I input a BMP w/ 4 colors, I’d like those 4 colors to be black through bright red (either automatically or manually selecting the threshold), instead of having to adjust the colors in the original BMP until it detects the 4 colors like I want.

I’ll try to think of other stuff, but that’s one I’ve run into a few times.


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 ;-))

that’s some good points, thanks!

i hope you still plan to enter the competition, runnerpack? we’ll have an open vote and everything is possible, as you said yourself! and most important, many entries would be a great thing for the vb community. πŸ™‚

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.

Hi Alberto,

I think what’s sorely needed is a good graphics editor + converter/exporter more than anything else.

Visual C++ Express Edition and Programmer’s Notepad are already very capable IDEs for GCC, and also allow you to run external tools like Reality Boy.

  • This reply was modified 12 years, 10 months ago by dasi.

it probably means a lot more work, but i think it would be great to have an all-in-one solution with vide 2.0. meaning source editor, graphics editors, sound editors and compiler and emulator integration combined in one environment. just like the current vide, but much more advanced.

it should be stand alone, and not require (possibly expensive?) external programs like visual studio.

so besides already mentioned things, this would mean that we need a much better integrated source editor.

if you have created bgmaps and such for a project, it’d be cool to be able to include them directly, without having to export the to a *.h file. i am not sure if it already is possible, since i did not use vide’s source editor, yet.

furthermore, we should think about a better concept for handling charset, since it is currently not possible to use chars from different charsets for one bgmap. maybe we could have containers in which 4 charsets can be conbined for a virtual char ram? probably someone can come up with a better idea to handle that.

if we stretch the container idea a bit further, we could also have containers of other kinds. like if you have a 3d bgmap, which consists of two sepereate maps, one for the left, one for the right eye, those could be put in a container, which could also have a red/blue 3d preview option.

that’s what i can think of now, but i will mess around with vide today, so probably more will come to my mind then. πŸ˜‰


vide should not open all charsets, bgmaps etc on startup, this can lead to crashs with bigger project files. πŸ˜‰

include *.h file option.

  • This reply was modified 12 years, 10 months ago by KR155E.
  • This reply was modified 12 years, 10 months ago by KR155E.

Oh… one other thing I just ran across… it’d be nice to be able to import another image file and merge into a previous one. Right now I have to copy/paste all my graphics into a single BMP, then convert all at once… which is kind of annoying when I just want to add a few graphics to something I did a long time ago.


two small bugs:
– if i select another program while vide is loading, it disappers
– under vista, transparency on the splash screen does not work, transparent color is black instead

One more thing that’d be nice is the ability to import an image larger than 512×512. We can do larger by combining BGMaps, but doing it manually is kinda a pain (need to remap the BGMap to point to correct places in the charsegs, unless you want to waste multiple charsegs)… and inefficient since there could be duplicate chars across multiple images.


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.

Zooming was a feature I thought of adding to the Advanced map editor plugin, but it didn’t make it to the release πŸ˜›

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.

Well, I’m not glad to hear you’ll be using “.BLOAT” but it sounds pretty powerful, yet easy to maintain. I’m just glad you have the time and willingness to work on it at all.

I’m sure most of us have our own ideas about how it should work/be written/etc., but you’re the only one who’s actually doing something about it. πŸ™‚

I’m intrigued about the emulation ideas and the debugging possibilities that functionality would bring. Just imagine editing a tile and having the changes instantly show up in the source, the ROM image, and the emulated VIP RAM, all while the game is running! And then add the functionality of DogP’s LPT link cable…

…I think my brain just imploded πŸ˜‰

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.

Maybe I’m late to the feature request but here is hope.

I would love to have the chance to decide if I want the map importer to do or not char optimizations, let me elaborate, for the animations in my engine (for example Mario) I use exactly 20 chars for each animation frame, and only one bgmap definition, so on each change of frame I write the char memory not bgmap, so the bgmap still points to the same chars in char memory. This way, I need to generate 20 chars for each animation, and each char must be in the same position. They way it works right now, after importing the image, I must manually copy each char from the bgmap to a new charset to have them properly ordered.

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 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!.


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 ;-))

jorgeche wrote:
I use exactly 20 chars for each animation frame, and only one bgmap definition, so on each change of frame I write the char memory not bgmap, so the bgmap still points to the same chars in char memory.

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?

And yes, use grit.

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.


Hello,i propoused why dont use a map editor which was done to vbjaengine,but why dont use next vide and its map editor for it?
It would be perfect both program which conect and easily add the code from the engine for making the animations,…

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.



Write a reply

You must be logged in to reply to this topic.