X2 project (20160404): directly- fix: empty path for preferences file if $HOME is not set or used.

I hope this is it. Can't loose time, I need to rest then move on.To reproduce the bug, I noticed:- display problem on Aranym + FalconTOS- not loading because path problem on Aranym + EmuTOS only (I usualy use MagiC over it).

HI,I test this version but still the same, under MiNT or MAGIC,after launch xenon2.prg no reaction, mouse is working, but desktop is not working, Menu of thing (Desktop) not working. Under TOS still the same exactly. Maybe someone who has a F030 with CT63 check how behaves this game ?

By "clean system", do you mean NVDI is absent or present? NVDI is stronly advised for display. I think it's mandatory if you have a CT60 with TTRAM. May be wrong but it helps disable the Blitter for TTRAM<>STRAM soft transfers.

I always forget, but it's supposed to run on Milan and Hades (GEM environment).

Hi,By "clean system"I understand NVDI is absent, but now I tested once again with NVDI, still the same. Another my problem how I can disable bliiter for TTRAM<>STRAM soft transfers in Falcon. I looking for in CPX.

You can't disable TTRAM<>STRAM transfers. Images are located in TTRAM for space and scene building. If the previous version was working, then the problem is not there.

I should advise you to give up with the current version and wait for next ones. You're the only one to have reported something. First thing when I'll resume work is to externalize the level maps table (level 1-5, x 1-20, y 1-1024 ints) into TTRAM. Current version uses GFA internal RAM, this location may have not enough space.

I am a little surprised but on my Hades this game has launched and after a while the main game menu was show. I have another problem about which in a separate thread, but works and is not on the Falcon with CT63

Next on the roadmap: collisions and explosions, ship damages and health bar...I hope to code a playable level 1 for Xmas. Still, level design is not my forte, a map editor is provided for all users.

For those who do not have a very fast Atari such as Falcon+CT60+SV or FireBee. This is from my FireBee, 640*480*256c. Speed is very good for a shoot'em up. It's a slower on my 1680*1050*TC32 usual setup, but still acceptable. Display is pure VDI: vro_cpyfm() for sprites, vrt_cpyfm() for masks. Bitmaps are located and mixed in TTRAM. If you have a CT60+CTPCI+Radeon or CT60+SV: Bitmaps are supposed to be located and mixed in VRAM.https://youtu.be/MYqVGuCJKmo

I'll fix some trajectories and number of creatures in future version, it's just details now. My wish is to recode the game, but the final result will not be exactly the same as the original game.

There's a paralax effect in mostly every version of Xenon 2. The scrolling may be slow because of this effect.

The mouse click may not react sometimes, but it's normal. Heavily bitmap computation. So better pause the game or click franckly a bit longer.

The scaling is possible if the *2 or *3 main window (border and widgets included) can fit in the screen. It slows very much the display.

Except from graphics (and maybe sound), all is from scratch. It's GFA code, no dissassembly of 68K original program. Original music will not be possible ; may be a mod file selector to choose the music, if I can manage both sounds (ym generated? sample?) and music.

Rajah Lone wrote:There's a paralax effect in mostly every version of Xenon 2. The scrolling may be slow because of this effect.

probably I never notice it so clear as now in your super smooth version

Rajah Lone wrote:The mouse click may not react sometimes, but it's normal. Heavily bitmap computation. So better pause the game or click franckly a bit longer.

so this is OS fault, right?which part of OS keep track of mouse clicks?

Rajah Lone wrote:It's GFA code, no dissassembly of 68K original program. Original music will not be possible ; may be a mod file selector to choose the music, if I can manage both sounds (ym generated? sample?) and music.

so everything we see is only GFA code?! wow!

what functions (command) do you use for bitmap manipulation? Only OS (system) calls?

calimero wrote:[so this is OS fault, right? which part of OS keep track of mouse clicks?

No really the OS fault. As said, heavy bitmap computation, which gives less time to handle mouse event. I use XaAES on my FireBee setup and MagiC on the Aranym setup for tests. So "Pause" the game if you want mouse correct reactivity. Closing the main window is equivalent to pause.

calimero wrote:what functions (command) do you use for bitmap manipulation? Only OS (system) calls?

Pure VDI means only the OS high level calls for the screen. The GFA sources are provided so everyone can launch Lonny's GBE to see the code. As for the OS calls, see the TOS.HYP VDI section (especially the raster functions). It's not difficult to understand.

- add: score, energy and lifes displayed in main window.- add: score and local highscore displayed in highscores window information bar.- add: sndh music routine from Manga Puzzle (not tested). Music is choosen in preferences with fileselector.

Reminder: this project is an attempt to code with GFA Basic, from scratch a shoot them up using the graphics of Xenon II. Need a very high end Atari machine or emulator, such as FireBee, Aranym, Falcon+CT60.You can use the GFA source code for your own projects.

I plan another release next week for bugfixes and sounds addition (last hope is to resample from FS-UAE and Audacity). Next on the roadmap is the inter-level shop with Crispin and others levels, but before that, I will pause for 3 months (prepare a trip to Vietnam) and ask for Bitmap Brothers' courtesy. I hope the project will remain open.If no authorization, then the projet will be canceled, and maybe used for another shooter or whatever game project.