News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_abalore

Alcon 2020 released

Started by abalore, 10:44, 20 December 20

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

abalore

24 hours after the game release one guy uploaded a video finishing the game in HARD difficulty level, without picking the speed power-up.
Is the game easy? hard? It depends on the player, I guess  :D

Shaun M. Neary

Quote from: abalore on 22:38, 22 December 20
24 hours after the game release one guy uploaded a video finishing the game in HARD difficulty level, without picking the speed power-up.
Is the game easy? hard? It depends on the player, I guess  :D
Also depends on how you look at it. It's pretty close to the arcade so the arcade tactics will also work.
I know for example, R-Type, a lot of the tactics I used in the arcade I was able to use on both CPC versions and they work for the most part. :)

Great accomplishment though. Be proud of this, sir! :)
Currently playing on: 2xCPC464, 1xCPC6128, 1x464Plus, 1x6128Plus, 2xGX4000. M4 board, ZMem 1MB and still forever playing Bruce Lee.
No cheats, snapshots or emulation. I play my games as they're intended to be played. What about you?

Gryzor

Quote from: abalore on 22:38, 22 December 20
24 hours after the game release one guy uploaded a video finishing the game in HARD difficulty level, without picking the speed power-up.
Is the game easy? hard? It depends on the player, I guess  :D

Where's that vid? Tried looking but nothing came up!

TotO

"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

Gryzor


Livingstone

There is a way to do an installation with M4 Board in a Z-MEM as in an X-MEM?  :blank:

TotO

#56
Quote from: Livingstone on 12:51, 23 December 20
There is a way to do an installation with M4 Board in a Z-MEM as in an X-MEM?  :blank:
The game do not require additional RAM. Only your M4 Board is required by loading the CPR.
May be I misunderstand your question. By the way, the Z-MEM is useless here.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

rexbeng

Good effort to recreate the arcade, although I notice (from videos tbh)... that's too low a framerate! Perhaps slower than 25 frames even?
Regardless, it would be interesting to take a look and discuss the technical sides of the three latest released vertical shmups; the different priorities and design choices made, compromises etc. Maybe a bit academic on one hand, but, hey why not!?

abalore

Quote from: rexbeng on 16:04, 23 December 20
Good effort to recreate the arcade, although I notice (from videos tbh)... that's too low a framerate! Perhaps slower than 25 frames even?
Regardless, it would be interesting to take a look and discuss the technical sides of the three latest released vertical shmups; the different priorities and design choices made, compromises etc. Maybe a bit academic on one hand, but, hey why not!?
The game draws 1 of each 3 frames, so framerate is 50/3. This is locked to be constant during all the gameplay. When unlocked, the game runs about 80% of the time at 25Hz (some areas at 50Hz). The reason for the lock is that I hate when games slow down. The priority in this game was the accuracy respect to the arcade. All enemies are the same size than the arcade and do the same movements and attacks, and also your own ship can be 5 modules width, all shooting at the same time. You can do whatever you want in the game and you hardly will see it slow down.
This is my decision for this game, in other future games maybe the priority is the frame rate, and I'll adjust enemy sizes or game mechanics to keep the frame rate over the target value. It's very easy to have constant 50hz when you have a maximum of 3 enemies of 16x16 on screen. In Alcon we have sometimes 3 enemies of 48x64 pixels plus a lot of other smaller ones, a myriad of bullets, 16 homing missiles flying around and your own ship upgraded to the max.

rexbeng

Thanks for the response! So, then, that is indeed a 17Hz game; but that sounds like the realistic option since you wanted to include as much content possible from the arcade. Still, good job on keeping everything tied to constant frame-rate and animation pacing. I personally am no fan of random-ish slow-downs or speed-ups either; or inconsistent animations.
I admit I regretfully didnt pay the needed attention (despite the coder had pointed it out) to how things moved faster in X (because of double-pixel resolution, heh) in one of my own games and am actually quite surprised by how not so many people noticed that!
Anyway, what is interesting is to get some insight on how going the cartridge way has assisted in making the game the way you did. What otherwise impossible hazards has it helped overcome. For example, would making the game for disk just mean that you'd have to 'split' it in three separately loading levels and that's it, or is there even more data being streamed while the game is running?

abalore

Quote from: rexbeng on 16:45, 09 January 21
Thanks for the response! So, then, that is indeed a 17Hz game; but that sounds like the realistic option since you wanted to include as much content possible from the arcade. Still, good job on keeping everything tied to constant frame-rate and animation pacing. I personally am no fan of random-ish slow-downs or speed-ups either; or inconsistent animations.
I admit I regretfully didnt pay the needed attention (despite the coder had pointed it out) to how things moved faster in X (because of double-pixel resolution, heh) in one of my own games and am actually quite surprised by how not so many people noticed that!
Anyway, what is interesting is to get some insight on how going the cartridge way has assisted in making the game the way you did. What otherwise impossible hazards has it helped overcome. For example, would making the game for disk just mean that you'd have to 'split' it in three separately loading levels and that's it, or is there even more data being streamed while the game is running?
A disk version of the game is not doable with the current level of detail. The game requires many memory blocks to be accessible simultaneously. In case of doing a disk version, it would run only in 128K machines and it would need to be severely downgraded.

millim

Dear all,

well, my question is ALCON related but actually addresses the X-MEM usage. I have ported the Caprice32 emulator to the Odroid-Go (OG) handheld. Now I am interested to play also ALCON on the OG. I am searching for a software reference how the X-MEM needs to be implemented in the emulator.

Any help welcome!
millim

XeNoMoRPH

unofficial home edition:



your amstrad news source in spanish language : https://auamstrad.es

Animalgril987


makinavaja

Quote from: Duke on 14:56, 20 December 20
You need to tick that option in the web config. This is to enable 512KB CPR files.
See the picture below (red circle).

As for the .BIN you need to upload it like it was a .CPR files, so |CTRUP,"alcon2020.v1.0.bin"

@abalore: Thanks for a fantastic game.
Hi
I cant find that binary dump for m4 boards on the website, and the cpr uploaded there doesnt works for me, even following the instructions activating the "use only 16 slots" :-/
Also,I'm having problems with the last version of ghost and goblins, so I supose its a problem with my config.


Any idea about this?

Duke

Quote from: makinavaja on 18:41, 11 March 21
I cant find that binary dump for m4 boards on the website, and the cpr uploaded there doesnt works for me, even following the instructions activating the "use only 16 slots" :-/
To make the Alcon 2020 CPR work with M4 board, you need to remove 8 bytes from the header (which is not part of the documentation I have seen for the CPR format).
See the attached picture and use a hexeditor to remove those 8 bytes.
-  I have made @abalore aware of this issue, but apparently wants to keep the 8 unused bytes (maybe some emulator depends on the fmt\0x20\0\0\0\0 tag).

makinavaja

Quote from: Duke on 06:11, 12 March 21
To make the Alcon 2020 CPR work with M4 board, you need to remove 8 bytes from the header (which is not part of the documentation I have seen for the CPR format).
See the attached picture and use a hexeditor to remove those 8 bytes.
-  I have made @abalore aware of this issue, but apparently wants to keep the 8 unused bytes (maybe some emulator depends on the fmt\0x20\0\0\0\0 tag).
Nice! Thanks for the info :)
Now the game boots, but only can play it several seconds until it freezes.  Also, it shows a few glitches on screen during while playing. :-/

Duke

Quote from: makinavaja on 21:45, 12 March 21
Nice! Thanks for the info :)
Now the game boots, but only can play it several seconds until it freezes.  Also, it shows a few glitches on screen during while playing. :-/
Then it sounds like you have not ticked "use 16 slots only", to support 512KB CPR's.

Animalgril987

Quote from: Duke on 06:11, 12 March 21To make the Alcon 2020 CPR work with M4 board, you need to remove 8 bytes from the header (which is not part of the documentation I have seen for the CPR format).
Hi Duke. Do we just change them to &0x00 or delete them, making the file 8 bytes shorter?

Alan.

GUNHED

http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

megachur

Quote from: Duke on 06:11, 12 March 21
To make the Alcon 2020 CPR work with M4 board, you need to remove 8 bytes from the header (which is not part of the documentation I have seen for the CPR format).
See the attached picture and use a hexeditor to remove those 8 bytes.
-  I have made @abalore aware of this issue, but apparently wants to keep the 8 unused bytes (maybe some emulator depends on the fmt\0x20\0\0\0\0 tag).

hello DUKE,

in fact for me it's ok for a RIFF format like CPR...

this is only a dummy chunk 0x666D7420 = "fmt " with 0x00000000 length

so your code should treat like that :
after "RIFF" analisys, etc...

currentChunk=readU32();

switch(currentChunk) {

case 0x414D5321: // "AMS!" - CPR Idetc.breakcase // cbxx ?
etc.break

default : unkown chunk ? skip length of data

the RIFF format is very open and you can add others chunk values in the future version... Skipping unknown chunk, will ensure your code compatibility with all versions ;-) !

GUNHED

Well, my idea would be to post the binary (512 KB EPROM content), so everybody can use it.
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

Joseman

#72
Hi
I post again only to say how great great great game it is.
I play several days a week and never get tired of it. The speed, the enemy IA, the graphics, music... the little things that are on all levels...
For me one of the best games on CPC, it is like being in front of an arcade machine or console.
Any news about the physical release? Is the game still being tweaked?

Regards

Gryzor

It is great, indeed it's a gem - really love playing it.

Animalgril987

Just crashed my 464 straight away. The screen looks like a call to MC_SET_MODE without SCR_SET_MODE, (hardware and software not in agreement about screen mode), and no keyboard response.


I have a 464 with M4. Normally with OS 1.1 in slot 31 and BASIC 1.1 in slot 0.
So I remove the 8 bytes that @Duke mentioned, in the Alcon file.
Set the M4 to 16 slots only and removed OS 1.1 and BASIC 1.1 ROM images. Reset M4 and CPC, and type |CTR. I just get the above crash.


2nd time, I couldnt even properly reinstall the ROM images via the web interface and had to delete romslots.bin and romconfig.bin from the SD card.

Powered by SMFPacks Menu Editor Mod