Future of CG version 0.4, you decide it!
-
- Vorticon Elite
- Posts: 1246
- Joined: Wed Dec 31, 2008 14:44
- Location: Frankfurt - Germany
- Contact:
Future of CG version 0.4, you decide it!
As version 0.3 of Commander Genius has finally been released we are working to release version 0.4. Again, we want to know what we could improve or add for the next version.
Please vote!
Please vote!
I once again voted for the seemingly easiest, and fastest-to-accomplish goal, the F1 screen.
Although we still need physics improvement. Playing mods on CG is still a lot harder than in the original.
Make enemies smarter sounds weird. Do we want to make them smarter than in the originals? But yes, I know there are some flaws with the monster behaviour in CG.
Although we still need physics improvement. Playing mods on CG is still a lot harder than in the original.
Make enemies smarter sounds weird. Do we want to make them smarter than in the originals? But yes, I know there are some flaws with the monster behaviour in CG.
You crack me up little buddy!
-
- Arachnut
- Posts: 891
- Joined: Thu Nov 01, 2007 2:35
- Location: Lancaster PA
- Contact:
- Deltamatic
- Vorticon Elite
- Posts: 1418
- Joined: Sun Apr 26, 2009 12:55
- Location: Shreveport, Louisiana
Help screen is easy, but not critical. Mod compatibility would be awesome, but not critical. More audio controls and special effects would be neat, but not critical. 4-6 and Dreams we'll want eventually, but now we're concentrating on 1-3. An in-game menu... still not critical. Performance, old card support, improved AI--not critical.
Exact physics IS CRITICAL. Hence my vote.
Exact physics IS CRITICAL. Hence my vote.
- DaVince
- lazy/busy Keener
- Posts: 1476
- Joined: Thu Nov 01, 2007 15:34
- Location: Amsterdam, Netherlands
- Contact:
About that... Hasn't anyone ever made any documents with useful calculations and formulae for this? I can't imagine nobody did, seeing as there are so many people who dive into the Keen executables to find and change stuff.tulip wrote:Although we still need physics improvement. Playing mods on CG is still a lot harder than in the original.
I voted better support for mods. Keen 4-6 should only be started on when Keen 1-3 AND mods work near-perfectly, I think.
Wow look at me I'm lurking
I take the viewpoint that the F1 screen will hopefully quickly get done, removing it from the list of tasks and allowing us to work on other things. Similarly, I think Keen 4-6 support should come last as it will take a long time and we haven't been able to perfect Keen 1-3 yet.
Bio Menace, yes, Dangerous Dave, yes, heck, even Shadow Knights... but Duke Nukum? Which game are you referring to that is supposedly related to Keen?other Commander Keen engine games such as Duke Nukem or Bio Menace?
What you really need, not what you think you ought to want.
-
- Vorticon Elite
- Posts: 1246
- Joined: Wed Dec 31, 2008 14:44
- Location: Frankfurt - Germany
- Contact:
That is something I really would like to know. There happened to be an article at slashdot, where someone reverse engineered the source code of keen1. Unfortunenately, the link is broken and I don't know if someone still has this file.About that... Hasn't anyone ever made any documents with useful calculations and formulae for this? I can't imagine nobody did, seeing as there are so many people who dive into the Keen executables to find and change stuff.
http://slashdot.org/comments.pl?sid=361915&cid=21372451
I really would like to know, how the calculations are done, since CKP only bases on ideas of the forum and aprroximations which are pretty ugly.
The good thing is that some of them share the file format that other games do (At least the concepts of a sidescroller). However, I see it more as future music, because we still need to tie up the code even for Commander Keen 4-6 and separate the engines the way, they don't disturb each other.other Commander Keen engine games such as Duke Nukem or Bio Menace?
I haven't had time to implement the help screen, as I'm still fixing issues with some mods. I have improved the story section using more C++ code and a new class which will also be used for the F1-help text.
I still have one Problem with the Help text. The Input howto is different in CG than in Commander Keen. F3 and F4 which are mentioned don't exist here anymore, as everything is setup in the menu. I'm thinking about just taking a small part of the original help text and fill the rest up with some own text about the CG itself.
The whole engine is redesigned at the moment, to be faster, easier to understand and to get rid of all the workarounds that were in the older version.
That takes a lot time, yes, and it's not done yet. But don't worry it's still being developed. You can check the clonekeenplus homepage, it also has it's forum, there you can see which issues are dicussed at the moment.
That takes a lot time, yes, and it's not done yet. But don't worry it's still being developed. You can check the clonekeenplus homepage, it also has it's forum, there you can see which issues are dicussed at the moment.
You crack me up little buddy!
http://files.commanderkeen.org/users/omp/keen1.c.txt
That is something I really would like to know. There happened to be an article at slashdot, where someone reverse engineered the source code of keen1. Unfortunenately, the link is broken and I don't know if someone still has this file.
I'm keeping this file and adding comments to it as I go along.
The original is http://www.quantumg.net/keen1.c.txt, but I've added a fair number of annotations in my copy, which might be helpful.
handle_ctrl at $5A39, move_left_right at $2B9A, and draw_level at $4B69 would be good places to start looking. Unfortunately I haven't really looked at the timing of everything. I do know that for each loop, the game records what buttons you have pressed down for that loop as well as the loop prior to the current one.
Code: Select all
#define input.direction 0x7FCA
#define input.jump 0x7FCC
#define input.pogo 0x7FCE
#define input_old.direction 0x7FD0 // these three appear to be the input from the previous frame
#define input_old.jump 0x7FD2
#define input_old.pogo 0x7FD4
I do know that keen has a velocity_x located at 0x6EFA in data segment and what I would guess is if the left/right keys are pushed down, one of the "think" functions (try think_13 for starters) that keen uses would notice this and add whatever to his x velocity.
Code: Select all
// seg000:391F (This is within think_13() )
if (reg_bx <= 6) {
// seg000:3924
switch(reg_bx) {
case 0:
case 1:
case 2:
// seg000:392B
PUSHI(2);
EMU_CALL(a_move_left_right, 3932, think_13);
reg_sp += 2;
Code: Select all
void move_left_right()
{
PUSH(bp);
MOV(bp, sp);
PUSH(si);
PUSH(di);
reg_di = MEMW(reg_bp + 4);
reg_si = 1;
// seg000:2BD5
while (reg_si <= MEMW(sprite_sync)) {
// seg000:2BA7
W_MEMW(sprite_copy.vel_x, MEMW(sprite_copy.vel_x) + reg_di);
if ((short)MEMW(sprite_copy.vel_x) > 120) {
// seg000:2BB2
W_MEMW(sprite_copy.vel_x, 120);
} else {
// seg000:2BBA
if ((short)MEMW(sprite_copy.vel_x) < -120) {
// seg000:2BC1
W_MEMW(sprite_copy.vel_x, -120);
}
}
// seg000:2BC7
if (reg_si != MEMW(sprite_sync)) {
// seg000:2BCD
reg_ax = MEMW(sprite_copy.vel_x);
W_MEMW(sprite_copy.delta_x, MEMW(sprite_copy.delta_x) + reg_ax);
}
// seg000:2BD4
reg_si++;
}
// seg000:2BDB
POP(di);
POP(si);
POP(bp);
RET;
}
And that's all I can tell you. Don't know how this sprite sync works though...