My games and many sources can now be found on GitHub.
The games come as projects for Vide – just download and open the projects in Vide to snoop at the code. If you are “just” interested in the binaries – you can find them on GitHub as well.
Last produced “Vide.jar” [27th March 2023] (for people who know how to use it)
Vectrex Integrated Development Environment.
!!! Mac Users – READ !!!
If you want to use a Mac with Vide there are two things you must know:
1) From OS version Ventura – the currently used JOGL Version does not work. This is due to changes in the operating system. You can still use Vide – but the emulation output looks pretty bad, since it uses Java “Swing” as output! (and is much slower).
2) I like distributing my software as a (one!) “zip” file containing everything needed.
Starting with OS Sierra – the Mac OS introduced a security feature called “AppTranslocation”.
(a good article about this can be found: App Translocation)
In short – if you just “unpack” Vide it will not work correctly and it will tell you it can not find “VIDE_HOME”.
A quick way to rectify the situation is to copy (copy! Not move, not link, COPY!) the unpacked Vide.app to (any) other location using the Finder (The FINDER – not command line!).
Also: Only move Vide.app alone, do not move Vide.app with other files/directories. ALONE!
The first time you open the application – do so via rightclick on the App and chose “OPEN” – you will be asked if you REALLY want to open, since the application is not “signed”. Confirm – and you should be ready to go!
For a complete walk thru of a Mac installation be sure to watch the Video:
Vide on MacOS Monterey
I checked, the process also works for Ventura! No need to make a second video!
More information on latest Mac adventures:
Java gives always 10.16 as “os.version” for a Mac. This can be circumvented by calling sw_vers and parsing its output (as long as one already knows the underlying OS is Mac OS).
Quotes in parameters are handled differently in different OS, Windows needs to escape quotes, Unix based OS don’t -> this produced the
“error: missing terminating ” character” error when compiling.
The executable flag of different files were missing, most notable from the “Vide” exectuable (the stub file to start Vide) and the “Vide.osx\Vide.app\Contents\PlugIns\Java.runtime\Contents\Home\jre\lib\jspawnhelper” (which is seemingly used to “exec” files from within java).
The Apple Gatekeeper and its AppTranslocation policies which I tried to explain before are seemingly more complicated than thought.
The instruction I found earlier seem to suggest, that copying an application using the finder will reset the quarantine flag (which downloaded apps have and which triggers the Translocation when first executed).
This is only partially true, the quarantine flag is ONLY reset if the App itself is not in a subdirectory, meaning you must copy the APP itself and it must not be contained in some directory structure. Also the App must be copied alone – not with other folders in one go! That is why my last Vide distribution was still translocated!
On Ventura (due to changes in Mac OS) some openGL functions do not work anymore. There is no new JOGL version for Java 1.8 (the java syntax is still 1.8 – but the binaries are compiled with a newer Java version und thus not compatible) – so openGL does not work anymore with Vide (Vide starts, but no Windows comes up).
I test at the start of Vide for Ventura (see above the “version”), if Mac OS Ventura is found, than openGL is disabled (display looks worse, and the overall emulation speed is slower).
In newer Mac OS versions each and every “unsigned” binary needs “manual” permission to be executed. I think a complete list of binaries that need to be manually approved is:
To run Vide:
Vide\Vide.app
Vide\lib\libjinput-osx.dylib
To be able to use the C-Compiler:
Vide\C\Mac\bin\aslib
Vide\C\Mac\bin\cc1
Vide\C\Mac\bin\as6809
Vide\C\Mac\bin\aslink
Vide\C\Mac\bin\binsplit
Vide\C\Mac\bin\srec2bin
Some image processing in the vector drawing tool:
Vide\externalTools\potrace\mac64\potrace
Vide\externalTools\autotrace\mac64\MacOS\autotrace
- Stable Vide download V2.51
- Latest Vide download V2.6 RC 3
Vide sources are also available on GitHub: Vide on GitHub
Beta / Release candidates
The latest release candidate version V2.6RC3 was uploaded 23th of February 2022.
Changelog: VideChangeLogRC.txt
! new March 27th 2023!
Watch this for installation information: Vide on MacOS Monterey
Stable version
Changelog: VideChangeLog.txt
Executable version V2.51 of Vide is available.
Updated to 2.5.1 archive on 3rd of April 2019.
From Vide version 2.5 onwards there are several Vide distributions. Due to many changes in Java, the last release was “troubled”. I decided to revert all changes I made to support Java 10 and higher.
Vide is now only “officially” supported running on Java 1.8. Since people may need other (newer) versions of Java, I decided that in the future I will distribute Vide with native packaging. This means in short, that Vide will run on its “own” Java installment. Vide is now independened of any Java version installed (or not installed) on your computer.
Since I still like to support different operating systems – this makes it necessary to offer different download versions for each operating system I support.
Please chose your download version accordingly!
(for this version you need an own Java version on your system (preferable Java 1.8))
Not native packaging: (800MB)
NOT VENTURA! (due to opengl – vide window will not open!)
Mac OSX: (930MB)
Win 64bit: (920MB)
Win 32bit: (920MB)
Ubuntu/Linux 64bit: (950MB)
Ubuntu/Linux 32bit: (950MB)
Debian/Linux 64bit: (950MB)
Due to the way Java native packaging works the directory structure is slightly changed. The “java executive” will always be kept in a subdirectory “Vide.app” (yes my main dev Environment is Mac 🙂 ). Due to the way Java works, the working directory of an application can not be changed during runtime (I mentioned that somewhere before).
I implemented two mechanisms that might ensure that Vide behaves the same as before:
- You can set a “VIDE_HOME” environment variable to point to your Vide directory.
- Or if no “VIDE_HOME” was found, Vide searches the current directory structure for its “home”, going “up” all the way to “/”
I define the Vide home directory as the directory where all the Vide subdirectories reside (“log”, “system”, “template”, “serialize”, etc). Vide needs those directories at a known position to work.
You probably need not be concerned – I just thought to mention it.
Command line Parameters
For the time being command line parameters will not work with native packaging. They are still “enabled” though, if you have Java 1.8 installed on your system, you can use the “java” Vide.
Starting Vide
Each archive unpacks in a single directory called “Vide”. In that directory all former subdirectories are listed and ONE executable:
- Java: a jar file Vide.jar
- OSX: an application “Vide.app”
- Windows: a batch file “Vide.bat”
- Linux: a shell script “Vide.sh”
Why that big?
- 320MB Vide + java native
- 100MB C-Compiler stuff
- 120MB Vectrex “roms” + documentation/images (used for the starter)
- 70MB Codelib – various Vectrex sources as examples
- 200MB documentation (“library”) of various stuff (hardware/BIOS/assembler…)
- 22MB external tools (autotrace/potrace/…)
- 70MB Vide help (many images)
- 135MB external libraries in “lib” directory (this is only needed if you want to compile the sources yourself)
- 10MB overlays
- 160MB example projects in the projects folder
- 10MB samples for speech synthesis
- 25MB source code of Vide
- 20MB xml files (various data, and vectorlist/animations)
- … and some additional small stuff
Release
Vectrex game – see blog at: Release blog
The above file is about 8.2MB in size. It contains all source code, all music, cartridge label, box title, instructions – everything.
There is even a “making of” history included which consists of 32 different “stages” of Release programming. The earliest from January 2017 when I did first tentative tests, without even the permission of the “Originals”.
That said, there are two textfiles included. One for the “user”, one in the source directory for the interested “programmer”.
For convenience sake, here direct links:
and:
Karl Quappe
UPDATE! 21st September 2020
Minor update, bug in demo mode removed, FLY (sprite) changed two “pixels”, due to not being 100% correct on cranky Vectrex. Also in demo mode on cranky Vectrex the homes were not displayed correctly.
Vectrex game – see Vide blog entries.
The above file is about 1.5MB in size. It contains all source code, all music, instructions, overlay.
That said, there are two textfiles included. One for the “user”, one in the source directory for the interested “programmer”.
For convenience sake, here direct links:
and:
hi, is vide ok to run/compile programs etc on a newer pc/os such as 64-bit windows 10? thanks! (any features of vide which have problems on a newer pc/os?)
Hi,
I am not sure how to answer the question. All information is provided on this page or in the documentation, which can be viewed without downloading the package.
Short answer – Try it!
Long answer:
It should. Vide is 100% java and should run on any system that supports Java. It has been tested on Win XP 32, Win 7 (32 and 64), Win 8 32/64, Win 10 (not by myself), diverse Linux (32/64), diverse Mac OS.
As you can read on this page there have been problems (speed) with some Windows installments that do have a “not nice” java version.
There are reports that on old machines Vide is to slow.
Vide uses in two places native binaries, which do NOT prevent Vide to run on all other parts.
a) Input devices, Vide uses JInput for input device support. As far as I know the library supports Win 10. All binaries come with Vide and are in the directory “lib”.
b) Potrace (for generating vector images from raster images). Binaries are supplied with Vide for the above platforms in the directory “externalTools”.
There have been reports that Vide does not dpi scale to windows settings if you changed these in the windows system settings. It still runs, but the font size is not scaled to windows preferences – which will most probably result in text output to be rather small in comparisson to other windows.
As far as I know Vide runs ok otherwise. But I do not give any kind guarantee.
Malban
I see VIDE 2.10 needs Java 10. Java.com doesn’t have that available for download, only Java 8 (at least not for Windows). I found Java 10 on the Oracle website, but I don’t see a JRE, only SE, which I assume will include the JDK and be a much bigger download & install. Is the Java 10 SE the version I should be downloading for Windows (32-bit and/or 64-bit) or is the a JRE hidden somewhere?
Looks like I found it archived here: https://www.oracle.com/technetwork/java/javase/downloads/java-archive-javase10-4425482.html
No Windows 32-bit version, so I guess I’m SOL for my ‘new’ retro development laptop, which is actually a 64-bit machine, but with only 2GB RAM, so running Win 8.1 32-bit.
You could also just use Vide 2.02 and use Java 1.8.
As written somewhere – I thinking of going back to Java 1.8 anyway – and distribute a Java version with Vide. Than all this searching for the right Java version will be done with.
But I actually thought I wouldn’t need to offer a 32bit version :-).
OK, I’ll go for 2.02, I can always use my main PC for anything special I need. My laptop PC might not have enough power to run it anyway, in which case, 64-bit is a moot point.
If it does run OK, I could put a 64-bit version of Linux on my old laptop, but that’s a diversion, I ran screaming from Ubuntu at least 10 years ago when it crashed and burned on me, retro computing is time consuming enough.
Yes, bundle Java with it, the only reason I have Java on my PCs is to run VIDE !
I tried 2.02 with Java 8 JRE 32-bit and it seems to run OK underneath, but the screen rendering makes it unusable. Windows don’t draw, overlap and don’t respond. I guess developing on retro PCs is a step too far.
Besides, the 1280×720 screen resolution isn’t really good enough for VIDE either.
Sorry to hear.
Next public Vide will probably be some time hence though…
just a head’s up that Vide does NOT like running on linux under Wayland.
It just ignores all mouse clicks, which is not fun.
You can switch to X11 instead. check your distro documentation/google for instuctions.
this command will show if you are using wayland or x11
echo $XDG_SESSION_TYPE
You are right – I never tried a Wayland configuration – actually I haven’t really used Linux since before Wayland was conceived.
That is actually a pure Java problem – and I have not seen an easy solution.
Perhaps there is a Java Swing distribution somewhere that supports Wayland natively – as for now it seem you might be able to use
WaylandX.
hi i need software for cartridge videojet 1220 (ds2431)
?
The UI on this download page has a flaw I think. The top download button (JAVA) is unadorned so it encourages you to consider all the buttons to be off by one (as in the label refers to the button above). But in fact the labels refer to the button below. Twice this has bit me on slow connections where I’ve downloaded the MAC version instead of the Windows 64 bit.
I’m sorry if this caused trouble. I placed a horizontal line between all downloads of Vide now, this should make it clear.
Got a bunch of errors : java.net.MalformedUrlException: unknow protocol: c when VIDE loads on Windows 10 64bits.
VIDE then works, i can create new project, new files , compile… i did a little project but then now when i go back to VIDE to load my project , when i open the project , i got again error : java.net.MalformedUrlException: unknow protocol: c and the project won’t load :(. So i can not work on it again , except recreate it each time…
Do you have an idea what is the cause ?
… as we messaged about the Problem via eMail…
The fault was, that the SAX xml parser package can not cope with “[” or “]” within path names to xml files.
Youki had those in his VIDE path – so he got the rather “strange” error… Fixed by moving to a “better” named directory.
Hi, I cannot get either the Mac OS app or the Java version to launch.
The Mac OS app complains that VIDE_HOME is not found despite the environment variable being set up in both my zsh and bash profiles. I can echo the value from Terminal (and have been switching the directory it points to depending on the version of Vide I’m trying).
The Java version crashes at start up with the following error:
*** Terminating app due to uncaught exception ‘NSInternalInconsistencyException’, reason: ‘NSWindow drag regions should only be invalidated on the Main Thread!’
My installed Java version is 1.8.0_271. OS is MacOS Big Sur 11.1.
Do you have any help or advice please?
I work on a MAC too – but a pretty old one – I can not install Big Sur, so I have no first hand experience.
But I am pretty sure there are users out there where it works.
I had “similar” (not the same) trouble with the apple software protection / directory schemes.
Perhaps this is “it”.
Be sure to unpack the “zip” to a location where everything can be accessed, and that the “unzipping” does what it is supposed to do. OSX has a software protection scheme which sometimes restrict the usage of ZIP, since depending on the location it does not unpack them to the destination but to an “aliased” directory.
Somewhere I had more information about this – but cannot find it right now.
If in doubt use a third party unpacker (or I think the CLI unzip also works), just not the OSX inbuilt zip support.
Does that help?
Thanks Malban, you’ve spotted the problem! It worked using iZip to extract Vide2.5.1.osx.zip and the extracted app runs with no problems. Unfortunately the default extractor from Finder, the unzip command in Terminal and The Unarchiver all produce non-working apps, even when attempting to update permissions using chmod.
However, even extracting using iZip, the pure Java version still crashes at start-up with the same error detailed above.
I’m relatively new to Macs myself so did not know about the zip extraction problem – thanks again! I’m looking forward to trying out VIDE and learning how to program for the Vectrex 🙂
Great!
The “pure Java” version.. is more a “goody” than really supported, since I must trust that your own Java version is compatible.
Sadly Java is not that compatible anymore with itself. That is why I chose to distribute a version of Java WITH vide which I know runs.
But as said, since I don’t have Big Sur… I can not test this… and it will stay the way it is.
Cheers!