|
Post by gtoal on Oct 6, 2017 19:55:07 GMT -5
I remember when you started this project waaaaay back. If you stall long enough and actually release the game you might beat my slacking "record" of 16 years from code start to release for "Spudster's Revenge". Something to shoot for. :-) I am setting myself a deadline of getting this out by Christmas. That is assuming that it is actually possible on this platform, and that I'm capable of doing it (or get help from experienced homebrew devs who'd be interesting in turning it into a collaborative project). In my defence I didn't really have time for fun projects until my recent retirement. Now I can put whole days into this (which it appears to need as there is a huge learning curve involved. It's not helped by having mislaid my Vecram and having to get by with the emulator, albeit the rather good one in VIDE that does model drift and flicker quite well) G
|
|
|
Post by gtoal on Oct 8, 2017 2:10:41 GMT -5
I added the digital joystick, all 4 buttons, and missiles tonight. I thought I was being smart with a clever trick to draw both left and right missiles with a single array call, using the center between the two missiles as the x,y coordinate of the combined object, and it sort of works - but it looks a little weird. I'm going to rewrite it tomorrow to use separate left and right missiles, and use the bios built-in rotate function to orient them towards the target. Something I couldn't do as well when the left and right missiles were fused into one object. I still have to complete the starfield rewrite as well - but at least now all the components (except the ships) have some sort of optimised implementation in place so I can get a better idea of how much work will be needed to add the ships and maintain a playable speed. (It is going to be touch and go, but I still think it is possible if I use pre-rendered vectors and a large rom)
By the way the hard drive on my unix died tonight. Fortunately I spotted it going partial a few days ago and ensured I had a 100% backup at all times (and a backup of the backup), but until I rebuild the system with a new drive, my Tailgunner project is going to be going a little slower. On the plus side, I'm fully migrated to the Vide environment under Windows now, so the project won't halt completely. I will miss emacs though.
Graham
|
|
|
Post by gtoal on Oct 9, 2017 2:13:36 GMT -5
Good to read that you still work on Tailgunner, Graham. I've tried to download the binary but atm there is no main.bin (your site doesn't display 404 errors, btw. This might be on purpose but a bit confusing.). Would be cool if you could provide the binary for trying out. OK, a test image is ready... gtoal.com/vectrex/tailgunner/main.binwith source in gtoal.com/vectrex/tailgunner/main.c.html ( gtoal.com/vectrex/tailgunner/main.c ) As far as I can tell from the emulator in Vide which has a profiling capability, it should perform at 50FPS. I appear to have about 10,000 cycles available in which to implement the enemy ships. (There are no ships yet) Let me know if it performs OK on the real hardware please. If you label the 4 vectrex buttons ASDF as in the emulators, then a mnemonic for what they do might be: Advance (ie insert a coin) Start Defend (shields) Fire The joystick code was taken from the Bloxorz demo and treats the joystick as digital. I have no idea if it will work on the hardware. Seems to work OK on the emulator using the cursor keys. Graham
|
|
|
Post by hcmffm on Oct 9, 2017 4:17:21 GMT -5
Thank you, Graham! I'll try on my real Vectrex, tonight.
|
|
|
Post by Rapetou33 on Oct 9, 2017 10:51:58 GMT -5
Thank you! I just tried it on one of my vectrex (European) and it works great. I am not really acute regarding game tests (others here are more focused on it) ; the only point is the shape of the aim thats not totally balanced on my screen ; left horizontal line seems to be shorter than right one. No sound it is a nice start : nice intro, depth effects, so please go ahead!
|
|
|
Post by gtoal on Oct 9, 2017 12:51:42 GMT -5
Thank you! I just tried it on one of my vectrex (European) and it works great. I am not really acute regarding game tests (others here are more focused on it) ; the only point is the shape of the aim thats not totally balanced on my screen ; left horizontal line seems to be shorter than right one. No sound it is a nice start : nice intro, depth effects, so please go ahead! That's the issue of vector drift. It can be corrected by recalibrating the beam to screen center every few vectors, but if you do it too often I think it slows the display down too much, so it's a question of either striking a happy balance between speed and quality for the majority of consoles, or having a calibration phase for each individual's machine before the game starts. I don't think the latter plays well so I'll be going for the former as soon as I've seen a recording of how it is currently. Malban recommends no more than 15 consecutive vectors, so that's probably what I'll go with. It means breaking display procedures into multiple sections. He must be right because the crosshair is 20 vectors (including the moves from one line to the next). I personally am very unlikely to implement the sounds. If anyone wants to take that on as a sub-project I would welcome it! Another thing could be done as a collaboration would be designing an overlay. I'm not sure much is needed except for the text areas. Those are low priority for me to do myself since I'm going to have my work cut out for me trying to shoe-horn the ship display into the remaining cycle time... (I'm planning back-up strategies in case full 3D isn't acheivable - for example making the gameplay more like the Vectrex Star Trek game where the enemy ships don't rotate. Hopefully not needed) G
|
|
|
Post by gliptitude on Oct 9, 2017 13:05:31 GMT -5
Hey I don't recall ever simulating insert coin on a Vectrex game. Interesting.
I tried the Tailgunner demo on Vectrex just now. The joystick control seems to work fine. .. It might be cool to have analog option for a game like this though. .. Also I would strongly prefer inverted Y axis for aim controls here, personally.
.. I'm not sure if this would be completely addressed by separating the left and right missile sprites or not, but I think the missiles look unnatural because they are coming from all different locations, as if each entire gun was tracking around without ever changing angle. I don't know how it works in the original arcade game but I know this is not how it works in the similar games of Star Hawk and Star Wars (and Vectrex Star Fire). In those games the guns have consistent locations where the missiles are always coming from. .. Maybe even your single array missiles would appear natural if they were consistently coming from the same spots at the bottom of the screen, (or side or whatever)?
Thanks for sharing the binary and code. I love to see works in progress.
|
|
|
Post by Malban on Oct 9, 2017 15:51:21 GMT -5
Hi! TG look much better than last time, good job! (sorry about what I last said... please don't keep grudges - I am a bit blunt sometimes) I have another small suggestion though. The placard data might be reduced a little bit - If I looked at it corectly you currently use 256 "frames" - which all together use about 16K of data. As long as you have enough space that is ok - but my estimate is, that eventually you might run out of memory. At the moment you "pulse" slightly above 50Hz in the "title". With my current compile setup. (that is no optimization and WITH framepointer...) For fun I tried compiling it with gcc setting "-O3" and "-fomit-frame-pointer" (you can edit the CFLAGS in Vide in the project window - popup on the root of the file tree). The produced binary was then optimizied (mainly for speed) and reached a size of 38k -> which could not be run. For convenience sake I just removed the placard (and the recording) and the result was about 17K. Anyway, what might interest you is, that the resulting binary was about 15% faster (which was not as much as I had hoped for, some compiles of mine had a speed increase of over 30%). BUT removing the framepointer and doing a "-O3" worked out of the box - so you might give it a try of you own. The "HIGH SCORE" and the "INSERT COIN" since "long" strings might need a reset0Ref in the middle - that does not use THAT much time - but would probably look nicer. The crosshair since its such a central part of the game should probably also be printed in at least 2 lists - at the moment it is a little bit "shifty". Playing on a "real" Vectrex: TG2.mp4Regards Malban PS Hehe - personal taste again... IMHO you should decide which compiler to use - the #ifdefs make the code not so well readable. Also the "#defines" which "translate" one BIOS header into another do not make things easier :-). And of course - you should decide pro gcc and vide :-). (But - well - that is VERY personal taste!)
|
|
|
Post by gtoal on Oct 9, 2017 16:42:20 GMT -5
Hey I don't recall ever simulating insert coin on a Vectrex game. Interesting. I tried the Tailgunner demo on Vectrex just now. The joystick control seems to work fine. .. It might be cool to have analog option for a game like this though. .. Also I would strongly prefer inverted Y axis for aim controls here, personally. .. I'm not sure if this would be completely addressed by separating the left and right missile sprites or not, but I think the missiles look unnatural because they are coming from all different locations, as if each entire gun was tracking around without ever changing angle. I don't know how it works in the original arcade game but I know this is not how it works in the similar games of Star Hawk and Star Wars (and Vectrex Star Fire). In those games the guns have consistent locations where the missiles are always coming from. .. Maybe even your single array missiles would appear natural if they were consistently coming from the same spots at the bottom of the screen, (or side or whatever)? Thanks for sharing the binary and code. I love to see works in progress. When I did the static binary translation of the Tailgunner rom for the GP32 & GP2X some years ago, I even added a recording of a coin dropping into the cash box :-) I had it saying "CREDITS n" at first too, but had to remove that as it pushed the vector count too high and caused flicker. But if it doesn't take up too much room and time, I'll leave it in just for fun. As I mentioned in the code I'm not happy with the way the missiles look and agree with your comments, but it *is* as efficient as I think may be possible, so I'm willing to live with the less tailgunner-like appearance until after the shiops have been added. Then if there are enough free cycles to implement the Cinematronics style missiles, I'll change it. By the way, they *do* always start at the same location but the first step is a doozy, and they missile y almost immediately increments to close to the cursor. I tried a version where the y step was restricted to a much lower maximum movement and it looked much worse. (There's been a few experiments with different effects in this code already that I've deleted from the source after determining that they look bad. On the plus side, the starfield is now an approximation that I originally thought would be too poor, but on trying it, it looked OK. For example, the star motion is now linear whereas the original effort had the stars reduce in speed as they approached the center in accordance with the rules of perspective.) I've always been a big fan of putting my code out there while I'm actually working on it. In fact I used to do development in a directory that was actually shared live on the net as a web page, though due to my current resources I no longer do that and just upload snapshots from day to day. If you have the right people around you it can be quite helpful for advice and code contributions. I'll look into the joystick suggestion. I don't know enough about the Vectrex hardware to just do it, but if possible I will try later. The original Cinematronic hardware actually supported both an analog and an 8-way digital joystick configuration, but every machine I ever played was set to digital, so although it may feel a little clunky compared to other vectrex games, I expect it will be quite close to the experience with the arcade hardware. Graham
|
|
|
Post by hcmffm on Oct 9, 2017 16:55:07 GMT -5
I just realized that I've lent both my VecMulti and my VecFlash. So no testing from my side, sorry, Graham! :-| Some time ago I had exchanged some few mails with John Hall, author of Minestorm, Fortress of Narzod, and Dark Tower. Not sure whether and how you, Graham, solved the dimming/fading of stars, already, perhaps John's interesting experience when programming Fortress of Narzod might help a bit. I hope it's o.k. for John to publish a part of an e-mail; it's a bit of Vectrex history and perhaps even useful for current Vectrex developers. . BTW: John Hall's website offers interesting info for both Vectrex fans and programmers. ... It's especially nice to hear your comment about the sense of depth. When I was writing Narzod, I tried to do the calculations for depth. The calculations took processor time and really messed-up what was being displayed. I made improvements in my math, but the end result still didn't look right. The problem really had to do with the animation. When writing the game, each refresh required that you perform the set-up for drawing and then perform the drawing. What was key was that you spent roughly the same amount of time on each refresh. I found that there could be large variations in the amount of time spent in calculation and there was no easy way to 'smooth-out' those variation from refresh to refresh. One refresh might run long and start to introduce flicker and short refresh cycles would cause jerky motion. Mark, Paul and I all wrote weird code to deal with some aspect of that problem. I finally trashed the math routines and used some simple look-up tables. These worked much better with minimal computation time. I remember feeling pretty smug that the tables worked so well - I used the same approach in Dark Tower. ...
|
|
|
Post by gtoal on Oct 9, 2017 16:59:12 GMT -5
Hi! TG look much better than last time, good job! (sorry about what I last said... please don't keep grudges - I am a bit blunt sometimes) I don't take offence easily, and especially not when the criticism is valid 128 frames - the array pointing to each frame duplicates a pointer to every second frame. That way I have the option of moving to even fewer frames without code changes. And half of them are with the text hidden, so only really 64 significant frames. I might move to 32 if I need the space later. I haven't yet tested that to see how granular the movement can be. I noticed it was a smidgeon below 50FPS but unless it is obviously flickery, I'm willing to leave it like that as this is only in the attract mode and there isn't any more to be added to it - you don't see ships at the same time as the placard for example. Actually I'ld be more inclined to optimise for size than for speed. It looks like the critical bottlenecks are all in the vector drawing which is done in the bios. I'm not sure that speeding up the game logic will actually make the game play faster? But I'll give it a try like you suggest and see for myself. Since the ship stuff is probably going to end up relying on precomputed vectors, space is probably going to be more valuable than speed. Yes, those and others are in my TO DO list. I know. I think I need to check the vectors and just be sure that it really is symmetrical! Then if it is definitely vector drift, I'll put a calibration in the middle of the vector list. Wiw - looks a lot better than I expected. I was fairly sure the flicker would be gone but the drift is less than I expected. Looks eminently fixable. One reason for supporting both compilers is that I get an instant check as to whether strange behaviour is my code or a compiler bug. What I *am* willing to do is code it with GCC as the primary compiler and use a lot fewer ifdef sections to map the cmoc bios procedures to the gcc names rather than mapping both to a set I defined myself. That should improve readability a little.
|
|
|
Post by gtoal on Oct 9, 2017 17:02:16 GMT -5
I just realized that I've lent both my VecMulti and my VecFlash. So no testing from my side, sorry, Graham! :-| Some time ago I had exchanged some few mails with John Hall, author of Minestorm, Fortress of Narzod, and Dark Tower. Not sure whether and how you, Graham, solved the dimming/fading of stars, already, perhaps John's interesting experience when programming Fortress of Narzod might help a bit. I hope it's o.k. for John to publish a part of an e-mail; it's a bit of Vectrex history and perhaps even useful for current Vectrex developers. ... It's especially nice to hear your comment about the sense of depth. When I was writing Narzod, I tried to do the calculations for depth. The calculations took processor time and really messed-up what was being displayed. I made improvements in my math, but the end result still didn't look right. The problem really had to do with the animation. When writing the game, each refresh required that you perform the set-up for drawing and then perform the drawing. What was key was that you spent roughly the same amount of time on each refresh. I found that there could be large variations in the amount of time spent in calculation and there was no easy way to 'smooth-out' those variation from refresh to refresh. One refresh might run long and start to introduce flicker and short refresh cycles would cause jerky motion. Mark, Paul and I all wrote weird code to deal with some aspect of that problem. I finally trashed the math routines and used some simple look-up tables. These worked much better with minimal computation time. I remember feeling pretty smug that the tables worked so well - I used the same approach in Dark Tower. ... Have to dash now, so a quick final reply in this thread... I believe I have come up with a rather nice and very optimised starfield - have a look at the code and see if you can work out what I've done :-) It looks better than perhaps it ought to! G
|
|
|
Post by Malban on Oct 9, 2017 17:29:44 GMT -5
PS
Just looked at a video of the original Tailgunner - The placard does not rotate in perspective - it just "shrinks"...
|
|
|
Post by Malban on Oct 9, 2017 17:34:27 GMT -5
Also... I hacked together a short dummy missile rotation. The missile was drawn pretty dumb it uses 8 different vectors, the routine therefor slows down pretty much - but anyway... Here is a bin and a project file (place it in ...Vide/project) if you want to look at it. Regards Malban vectrex.malban.de/tmp/TGMissile.zipvectrex.malban.de/tmp/TGMissile.bin
|
|
|
Post by hcmffm on Oct 9, 2017 17:54:29 GMT -5
... I believe I have come up with a rather nice and very optimised starfield - have a look at the code and see if you can work out what I've done :-) It looks better than perhaps it ought to! The star field (shown in Malban's video) looks really very good. No need to improve that.
|
|