Qbasicnews.com

QBasic => QB Projects => Topic started by: Rokkuman on December 13, 2002, 10:37:44 PM



Title: Cobra
Post by: Rokkuman on December 13, 2002, 10:37:44 PM
Hey, I'm making a fighting game called Cobra which is in my opinion, the best fighting game for QB. I want it to compete with QB BAttle arena which I might lose against but anyway, I want to know if anyone has any ideas for it. Character designs, moves, stages, anything. My game features side scrolling and probably the first to have high rising vertical jumping, (like most of capcom and marvel's vs series) I have five characters done so far, so if you have any ideas, let me know.

EDIT: *cries*

EDIT: Hey! It's been two years since I made this post. Awesome.


Title: Re: The Best Fighting Game: Cobra!
Post by: Hexadecimal Disaster on December 14, 2002, 12:13:00 AM
Quote from: "Megaman"
I want it to compete with QB Battle arena which I might lose against...


Wow! Very optimistic about your game, I see.  :-?

It wouldn't be the first time that some QB project is cancelled, and if -by some unexpected thing- Vance's brawler is cancelled/delayed... you can be the only winner! (Vance probably will finish his game before you, but hey!, think positive! (http://www.handykult.de/plaudersmilies.de/rofl.gif) )

So you want suggestions? Just watch your favorite fighting game and try to implement as many features you can!

Anyways. Where can I download the demo?  :wink:


Title: Cobra
Post by: LooseCaboose on December 14, 2002, 12:49:12 AM
I am in the process of implementing flat EMS memory handling into QBDBZ. I have functions that work in a similar fashion to C's malloc and free which allows me to allocate a block of memory in flat EMS and return a pointer to it. All of the player data tables have now been pushed into upper memory, which leaves me with absolutely (fingers crossed) no memory hassles and allows characters to have hundreds of moves and very complex move animation.

Team fight is a cool option, players select more than one character (mine allows up to 5) and when a character is killed, the next jumps in to take their place. Unbalanced teams (ie 5 on 3) can help novice players or make for harder difficulty levels. You could also do a tag-team mode.

Special moves are probably the make and break for fighting games, players like characters to have lots of em, and for different characters to have different moves. A fighting game quickly gets boring if every character has the same slide kick, fire ball and uppercut. Supers, combos, power struggles and finishing moves all enhance a fighting games fun factor and replay value.

Mortal Kombat 4 had weapons which was an interesting idea. Bonus rounds (like street fighters car smashing stage) are always fun. Secret stuff (levels, characters, gimmicks) can make a game more interesting and add a bit of replay value. A good story doesnt hurt either.  

Good luck with the game


Title: Cobra
Post by: Hexadecimal Disaster on December 14, 2002, 12:54:14 AM
Quote from: "LooseCaboose"
I have functions that work in a similar fashion to C's malloc and free which allows me to allocate a block of memory in flat EMS and return a pointer to it.


Oh! Just note that this's QB and not C. So cross your fingers... and your toes too.  :D


Title: Cobra
Post by: wizardlife on December 14, 2002, 01:09:05 AM
I want to make a vertex-only (skeleton-model) fighting game sometime... I think QB is just a little too slow, though... even for that...


Title: Come on...
Post by: Rokkuman on December 14, 2002, 03:49:57 AM
----Erased message be cause he cringes in pain every time he reads it because it made abselutely no sense to post it in the first place...---


Title: Best fighting game...
Post by: Ryan on December 14, 2002, 04:33:23 AM
The absolute best fighting game I've played in QB is SFB2: Vector Warriors by Kevin Reems.  It is 3D wire frame with particle effects and animated levels (and fast, too).  Pretty cool stuff.  If anyone knows a download site for it (I've seen one or two) could they post it?  If not, I can zip and upload the copy on my HD.


Title: Cobra
Post by: Antoni Gual on December 14, 2002, 12:26:28 PM
Kevin Reems's page is at
http://members.cox.net/kreems/
It does'nt work at all in Opera and tries to download something in IE, a thing I will not allow in my computer. If anyone is  willing to take the risk...


Title: His page
Post by: Ryan on December 14, 2002, 05:00:35 PM
Very fancy layout with a lot of Javascript stuff going on.. and some other things, but I'm not too familiar with it all.  :)  He does have a download for Vector Warriors there, and some screenshots though they're messed up GIFs.  The page loads at an IP address, so I'm not sure if this link will work or whatever, but here's the download:

http://68.7.40.166:81/Expression/downloads/sfb2-104.zip


Title: Cobra
Post by: _Bill_ on December 14, 2002, 05:49:26 PM
Yep it works.


Title: Cobra
Post by: Hexadecimal Disaster on December 14, 2002, 06:18:31 PM
The first time I saw that game I couldn't manage it to run. Gonna try again...  :(



EDITED: Now this time it worked. Really nice, but confusing sometimes. The fact that some people thinks that "Mortal Kombat" is a good game is scary, though.  :o


Title: Cobra
Post by: na_th_an on December 14, 2002, 07:39:19 PM
Really Scary

Has Mortal Kombat any *good* feature?

Nothing to do against SF series, KOF series, FF series, ... ... ... I still love my one and only Street Fighter 1:

(http://usuarios.lycos.es/firstqbasicforum/stuff/sf10001.png)

Should I start a QB version of SF1, now that QB Fighting Games are in fashion? :D:D Naaah... I have some project involving little funny pigs...

Later...

The most difficult thing I've found when I ever though of making a fighting game is the variable-sized sprite feature. I can think on several sollutions, but none of them would be completely satisfactory. What have you done, guys, to solve this? Are you using some kind of sprite editor to place center/action points in the sprites? What kind of data structures are you using?


Title: You say you want cameos.
Post by: Rokkuman on December 14, 2002, 08:20:50 PM
You all say that you want Qbasic cameos. I know Nathan wanted Jill, so who else should I include. Don't put too many, because the majority of the game's characters are original.


Title: Cobra
Post by: na_th_an on December 15, 2002, 12:38:10 AM
I dunno if this will be useful, but anyway here it is:

(http://usuarios.lycos.es/firstqbasicforum/stuff/JILL.gif)

Those are Jill The Goddess' original graphics. 16 colours so easy to port to another pals.


Title: Cobra
Post by: LooseCaboose on December 15, 2002, 01:14:15 AM
Quote

The most difficult thing I've found when I ever though of making a fighting game is the variable-sized sprite feature. I can think on several sollutions, but none of them would be completely satisfactory. What have you done, guys, to solve this? Are you using some kind of sprite editor to place center/action points in the sprites? What kind of data structures are you using?


I have sprite tables loaded for each character (these are now in EMS since they are generally only read from). A sprite table entry stores the width and height of the image, an x and y offset (this for instance allows frieza to float above the ground) and the hit and attack regions.

I chose this approach because it was simple and flexible. The hit and attack regions (boxes) help fix bounding box collision problems (ie some kick frames have heaps of empty space in them). The spriteTable also stores a page and offsets to grab the sprite from (sprites are all stored on 'plates' in EMS video layers). To save memory and time, each frame is only sprite is only stored facing left and can be flipped (thanks to DQB) during rendering.

The different coloured character clothing for mirror matches is done with DQBs blender map feature. The blender map is applied when the character is loaded and then freed so that it doesnt take up any memory. I will most probably release the source for the game with the next release, including the tools (once I tidy them up) I use for creating characters. My game engine is flexible enough to allow people to easily create other fighting games using it.


Title: Sorry
Post by: Rokkuman on December 15, 2002, 01:26:31 AM
Maybe Nathan, I can get Jill to be a fighter in the game, but she could also make a cameo.


Title: Opps, my bad.
Post by: Rokkuman on December 15, 2002, 03:14:20 AM
Edited: I didn't say nothin.


Title: Canceled
Post by: Rokkuman on December 15, 2002, 06:51:57 AM
Didn't say nuthin either.


Title: Cobra
Post by: na_th_an on December 15, 2002, 11:31:23 AM
Hey, megaman, don't give up so easily. QB has memory problem, I had memory problems since Level 2 in Jill (and it has 8 levels, so imagine that!), and there is always a sollution.

Let us help you and don't cancel the project !! :D

LooseCaboose: Basicly it is the same technique I had thought about. I should need self-made tools to place the sprites offsets and collision boxes, and then a good memory management system to store the sprite data... I'm still so dull programming to do such a difficult task in QB. It would be far too easy in flat addresing 32 bits C with allegro :P

Anyhow, when I finish LONG and my coshino's (pigs) game, I will try.


Title: Cobra
Post by: Hexadecimal Disaster on December 15, 2002, 04:18:29 PM
Loose's way of making his game is the correct one. I used my own approach -that's it: "first working and then improving"- in BB: BTROH (the first game in the series) just using pixel-perfect collision detection. This has the big disadvantage that the whole "hit frame" can hit, that's it, if you throw a kick the whole body can harm the opponent. Advantages? Mainly the fast implementation and very low memory requirements (you're saving the "body box" and the "hit box" tables). And since BB2: FFF is partially based on the previous engine... well, you can guess which method I'm currently using.  :D  Yeah, yeah. That will be corrected soon... but using another different technique.  :wink:  (Mainly trying to save memory; I'm already suspecting some possible unstability in the game due to memory issues)

And PJ... are you already throwing the towel?  :o  What happened with the guy who claimed "The Best Fighting Game: Cobra!"?

(http://www.hulla-balloo.com/vplanet/qbcbfr1.gif)
C'mon! Memory isn't an excuse with that sprite size! Optimize your code, mein freunde!

(http://usuarios.vtr.net/~disaster/saishu.gif)
Look, the saishuukanketsusen sprite, plus Kasumi, gives a bit more than 200x200 in sprite size. Just pick your calculator and see how many memory that move eats. Optimize your code, and try to use as many XMS / EMS memory as possible. And... well, everybody knows that I'm somewhat reluctant to post screenshots of BB2, but this time is special: DON'T GIVE UP, PJ! (http://www.handykult.de/plaudersmilies.de/happy/xyxthumbs.gif)










(and on a side note, stop double posts!)


Title: WAIT IT'S NOT CANCELLED
Post by: Rokkuman on December 15, 2002, 04:43:11 PM
I fixed it, it's not cancelled!


Title: Cobra screens.
Post by: Rokkuman on December 15, 2002, 04:52:54 PM
If anyone has a websie, cn I post some of my pics on it so  can show them to some people?

Because I hate that pic, it makes the game look so cheap!


Title: Cobra
Post by: Hexadecimal Disaster on December 15, 2002, 05:16:00 PM
Good to see that.  :D


Title: Re: Cobra screens.
Post by: wildcard on December 15, 2002, 08:25:41 PM
Quote from: "Megaman"
If anyone has a websie, cn I post some of my pics on it so  can show them to some people?

Because I hate that pic, it makes the game look so cheap!


You can use http://www.qbasicnews.com/cgi-bin/qbnimg.pl and just private message or email me and I will send back the URL to the pics.


Title: Cobra
Post by: Piptol on December 15, 2002, 08:30:49 PM
Quote from: "Hexadecimal Disaster"
And... well, everybody knows that I'm somewhat reluctant to post screenshots of BB2, but this time is special: DON'T GIVE UP, PJ!



Umm.. isn't that a King of Fighters screenshot? :???:  The background is certainly familiar..


Title: Cobra
Post by: Hexadecimal Disaster on December 15, 2002, 09:24:51 PM
Whoa! That must be KOF 2008, where the blond Yuri attacks hip-hop-themed-Guy with Power Geyser-esque attacks.  :o








(http://usuarios.vtr.net/~disaster/estadio.gif)

Yep. That must be a fake.  :evil:  (BTW, note the real-time image on the scoreboard of the stadium)


Title: Cobra
Post by: toonski84 on December 15, 2002, 10:17:37 PM
actually, i figured this out while playing a poorly emulated kof game.  the sprite sizes are not variable, but blocks of 8x8 & 16x16 sprites.  that's how collision detection works on those games too...


Title: Cobra
Post by: toonski84 on December 15, 2002, 10:18:31 PM
hey megaman.. have you actually *made* this engine?


Title: YEs I have
Post by: Rokkuman on December 15, 2002, 10:28:18 PM
Cobra is playable, however it's not done. I don't talk about a game until it's at least playable.

So therefore, yes I have made the engine, I'm currently working on characters and their moves.


Title: Cobra
Post by: na_th_an on December 16, 2002, 01:33:26 AM
Megaman, glad to know that you're keeping on with the project.

Toonksi: I knew about that feature. Most 2D consoles/systems use 8x8 or 16x16 sprites. I found that sollution very cool 'cause in the characters there are many zones which are fully transparent, so you're saving memory. Also, you can give "collision status" to only certain sprites, then you're done.

What I was lacking is a big-sprite builder out of small sprites... And that was where I was lazy on :D

HD: Your game will be the best QB game ever, if that which shows is in full movement.

LooseCaboose: You're implementing such nice features more appart these ones found in the reviewed demo. I am really waiting to see the finished product. It will rock :P

Megaman again: C'mon man, post another screenshot. I can host them for you, if you need them, but you better use wildcard's facility.


Title: Screenshots
Post by: Rokkuman on December 16, 2002, 01:48:35 AM
Thanks Nathan, I'll post screens as soon as wildcard gives me the URL. I've already sent the pics to him.


Title: Cobra Screeshots
Post by: Rokkuman on December 16, 2002, 12:54:49 PM
The Screenshots are only of one stage,  and they do seem sort of lame, and the characters are in the same place in all of them, but I guarantee the game is better. Somethings the screenhots can't tell is that it does scroll sideways, and when I take another one, it will be a different stage.
(http://qbasicnews.com/users/Megaman/cobpic1.jpg)
(http://qbasicnews.com/users/Megaman/cobpic2.jpg)
(http://qbasicnews.com/users/Megaman/cobpic3.jpg)
(http://qbasicnews.com/users/Megaman/cobpic4.jpg)


Title: Cobra
Post by: Piptol on December 16, 2002, 05:38:47 PM
Quote from: "Hexadecimal Disaster"

Yep. That must be a fake.  :evil:  (BTW, note the real-time image on the scoreboard of the stadium)


It's not that I thought it was a fake Hex, I  just didn't realise you'd ripped the graphics out of other games. That's fine as long as you make that clear. To be honest, I don't care so long as it plays well. Good luck with it.

(http://piptol.qbasicnews.com/stuff/evi1.jpg)
(http://piptol.qbasicnews.com/stuff/evi2.jpg)


Title: Cobra
Post by: Hexadecimal Disaster on December 16, 2002, 06:38:28 PM
I -always- said that the whole BB saga is based on ripped-but-at-least-edited-with-some-personality-sprites. Currently (and the game still looks somewhat bad, IMHO) the engine uses about 160+ sprites of 70x70 (average) per character, including victory poses and the such... and you expect 100% original characters? Naaaaaaah. :P





BTW, nice screenies PJ. I presume that since your game allows high-jumps it also have a good "air combo/aerial rave" system, isn't it?  :-?


Title: Cobra
Post by: wildcard on December 16, 2002, 07:56:09 PM
Quote from: "Hexadecimal Disaster"
. Currently (and the game still looks somewhat bad, IMHO) the engine uses about 160+ sprites of 70x70 (average) per character, including victory poses and the such... and you expect 100% original characters? Naaaaaaah. :P


Well just think, if you started now doing the graphics your grand kids could atleast play it ;-) And you could write the whole game in pure qb, based on the rate of speed of processes in 202020 which the game would be released ;-)

Will BB2 ever see the light of day? ;-) Just/kidding(joeking?)


Title: Cobra
Post by: Piptol on December 16, 2002, 09:07:58 PM
Quote from: "Hexadecimal Disaster"
I -always- said that the whole BB saga is based on ripped-but-at-least-edited-with-some-personality-sprites. Currently (and the game still looks somewhat bad, IMHO) the engine uses about 160+ sprites of 70x70 (average) per character, including victory poses and the such... and you expect 100% original characters? Naaaaaaah. :P


OK :)

Where can I get the first game? I'd really like to see it.


Title: Cobra
Post by: Rokkuman on December 16, 2002, 09:24:25 PM
Quote
BTW, nice screenies PJ. I presume that since your game allows high-jumps it also have a good "air combo/aerial rave" system, isn't it?


Uhhhhhhhhhhhhhhhhh, maybe.
[/quote]


Title: Cobra
Post by: na_th_an on December 16, 2002, 09:25:57 PM
Megaman: Your screenshots simply ROCK!!! I love that style in GFX. Go ahead!!!


Title: You like those shots.
Post by: Rokkuman on December 16, 2002, 11:00:57 PM
I honestly don't see how you can even tell what's going on with those pics. However I only have myself to blame, I'm a horrible photographer.


Title: Cobra
Post by: toonski84 on December 17, 2002, 08:45:54 AM
hehehe.


Title: Cobra
Post by: relsoft on December 18, 2002, 03:32:16 AM
Hex: I told ya, release or be bugged!!!! BTW,  don't you think Iori Yagami with Genso's head look amazing in BB2/3?

Note: No IORI no Reverse GET routine......


Arrrrrrgh@@@@@!!!!! I have to dance he Asereje tomorrow for our Christmas party at the office.... F&*CK!!!!!


Title: Cobra
Post by: Piptol on December 18, 2002, 03:59:54 PM
Quote from: "relsoft"
Hex: I told ya, release or be bugged!!!! BTW,  don't you think Iori Yagami with Genso's head look amazing in BB2/3?

Note: No IORI no Reverse GET routine......


Well if he doesn't want pesters he shouldn't release pictures :P

Quote
Arrrrrrgh@@@@@!!!!! I have to dance he Asereje tomorrow for our Christmas party at the office.... F&*CK!!!!!


Damn, I hate that song. I spent the summer in Spain and it seemed to be the only song they had there (that and Ave Maria :barf: )


Title: Cobra
Post by: toonski84 on December 18, 2002, 07:50:06 PM
is that the 'next macerana' thing?  i havent even heard it and i hate it.

so lemme recap:  we got bastard battle, the kof clone which is/isnt in qb?  cobra battle, which are the simpler bright colored screenshots, and qb battle arena which is vance's fighting game?  any others?


Title: COBRA
Post by: Rokkuman on December 18, 2002, 10:54:27 PM
Cobra, not Cobra Battle, thank you very much! 8)
You left out QBDBZ.


Title: Cobra
Post by: LooseCaboose on December 19, 2002, 12:02:06 AM
Quote

You left out QBDBZ.


Dont worry, nobody pays attention to me anyways. Guys? Guys......? :cry:


Title: Cobra
Post by: . on December 19, 2002, 02:31:10 AM
*crickets*


Title: NEW STAGE
Post by: Rokkuman on December 19, 2002, 02:43:07 AM
I made a new stage.


Title: Cobra
Post by: toonski84 on December 19, 2002, 08:53:46 AM
i didnt count qbdbz because it's already been released, silly :P

.... or has it *eyes widen*


Title: Cobra
Post by: LooseCaboose on December 19, 2002, 07:48:49 PM
Im thinking of calling it "DragonBall Evolutions" at the moment. Mainly because the story mode will have hypothetical stories for each character, for example (for those that follow the dbz universe), Vegeta's story has him fighting the Ginyu force and Freiza because Goku is still otherwise incapacitated back on Earth.

What do you guys think?


Title: Where do you get those sprites?
Post by: Rokkuman on December 19, 2002, 09:34:19 PM
Hey Loose Caboose, where do you get those sprites from? I haven't seen them in any DBZ game.


Title: Cobra
Post by: toonski84 on December 19, 2002, 10:42:26 PM
my first guess is that they're ripped from the snes fighting games.  and they do sorta look like 'em.  but dont try and model that gameplay.  those games weren't very fun.  i'm not really a huge fan of the show, and it kinda bored me.


Title: Cobra
Post by: LooseCaboose on December 19, 2002, 11:17:50 PM
Quote from: "toonski84"

my first guess is that they're ripped from the snes fighting games. and they do sorta look like 'em. but dont try and model that gameplay. those games weren't very fun. i'm not really a huge fan of the show, and it kinda bored me.

Huh, blasphermy. Although I disliked the Americanised version of the DragonBall saga, I have seen most of the Japanese episodes now and they are much better (Funimation went as far as totally rearraging the story in some places).

Im not exactly sure where the graphics originate from, I stole them from Mugen (which had pre-ripped characters in a format that I could convert quickly using some tools I wrote). I think they are from one of the early playstation games that never got released outside of Japan.

Did you dislike the gameplay of the snes games, or QBDBZ or both? Im still working on it and still completely open to suggestions and critiscism of course (otherwise Id be a complete hypocrite - see Quake Basic thread).


Title: Faster
Post by: Rokkuman on December 19, 2002, 11:39:32 PM
I noticed that while playing your demo, it was a bit too slow. And this may sound sort of nitpicky, but fighting games seem a little more professional when there's a momentary pause when an attack connects.

Stupid Question: What's a hypocrite? I know you all think I'm stupid, but it's just one of those words I don't know yet.


Title: Cobra
Post by: LooseCaboose on December 19, 2002, 11:52:45 PM
Did you try playing with the speed settings in the configuration menu. It should run at an acceptable speed on any pentium machine. Im thinking of implementing a proper gametick counter so that the games speed is capped ands runs the same everywhere (although slower machines would get jerky gameplay).

Not sure about the momentary pause thing, I like fast fighting games, I could included it as gameplay option though.

A hypocrite is someone who doesnt practice what they preach, eg saying "All men are equal", while showing racial or social prejudice is hypocritical. Because I have been critiscing others work and ideas and arguing lots in the Quake Basic thread (among others), I am quite open to criticism and nitpicks over my projects. Constructive critiscism can really help a project out rather than having everybody falsely tell you its brilliant.


Title: Thanks
Post by: Rokkuman on December 19, 2002, 11:55:08 PM
Oh, I didn't know the configuration worked! :)

If you can make the pause right, it will be perfect. Look at Street Fighter Alpha 3. That game is fast, but by adding the momentary pause just right, it looks cool and the hits seem to have more impact.

Oh, that's what a hypocrite is.

Thanks


Title: Cobra
Post by: toonski84 on December 20, 2002, 12:17:22 AM
the snes games.  i havent played qbdbz enough to grasp it completely (i prefer to wait for the finished version when possible).

you know, megaman, while sfa3 is a great game, the capcom formula has been done.  and done. and done.  it might be fun to see some new twists on fighting gameplay.


Title: Just the Pause.
Post by: Rokkuman on December 20, 2002, 02:20:57 AM
I'm just talking about the pause, that's all.


Title: TADA!
Post by: Rokkuman on December 20, 2002, 02:27:49 AM
And now for the moment you've all been waiting for... WHO WANTS A NON USER INTERFACIAL DEMO OF COBRA THAT IS SOMEWHAT PLAYABLE! Private message or post it if you want one. Read the
in-game help, the "How to Play" section isn't added yet.


Title: Cobra
Post by: relsoft on December 20, 2002, 02:31:02 AM
I'm the first to test it.....

C'mon mega post the url.  I could host it for ya if you want... :*)


Title: COBRA DEMO
Post by: Rokkuman on December 20, 2002, 03:37:00 AM
Here's a bad demo of Cobra, the reason it's bad is because it still has some "holes" in it, but it's playable and two player can be pretty fun.


http://relsoft.wrq.cjb.net//files/Cobra.zip


Thanks Rel!


Title: Cobra
Post by: relsoft on December 20, 2002, 04:16:32 AM
For a 13 year old kid, you're skills are quite amazing!!!! Good job!!! Now you're ready to graduate to Libs.

Milo's multikey routine would do wonders to your game. Trust me. :*)


Title: Thanks
Post by: Rokkuman on December 20, 2002, 04:20:29 AM
Thanks. I've been working on this for about 3 months, (due to procrastination...)


Title: Cobra
Post by: relsoft on December 20, 2002, 04:25:12 AM
Bah!!! I've been working on mine for almost 2 years now! lol


Title: Thanks
Post by: Rokkuman on December 20, 2002, 04:54:43 AM
Haha, well, just in case it's scrolled down too much, scroll up a little and there's a demo of Cobra. Tell me how you like it.


Title: Cobra
Post by: relsoft on December 20, 2002, 05:06:09 AM
You might wanna put this:

http://relsoft.wrq.cjb.net//files/Cobra.zip

on your sig.

:*)


Title: Cobra
Post by: na_th_an on December 20, 2002, 09:03:40 AM
This game rocks, man! Are you planning to add IA?


Title: Cobra
Post by: toonski84 on December 20, 2002, 09:26:39 AM
heh, this is cool! sorry i lowered my expectations, because you are an above-average coder for your age!

i like the physics, keep up the good work!


Title: Yes there will be IA :)
Post by: Rokkuman on December 20, 2002, 01:25:29 PM
Yes I will be adding AI, I had a little bit of AI at  first, but it was just downright stupid. So I erased it and I'm starting over.


Title: Cobra
Post by: LooseCaboose on December 20, 2002, 09:58:03 PM
I had a quick play, really good work so far. Youve got some nice features and the simple cartoon style graphics complement the game really well.

Who taught you to code, I have seen university students who cant code that well, very structured, very organised. Good work.


Title: Apinyinz
Post by: Rokkuman on December 20, 2002, 09:59:21 PM
So, all of you who tried the demo. Did you like it? Not like it? Do you have any ideas or opinions about it? I'm open to anything.

LooseCaboose: I just read some books, and have looked at some other people's game codes.(NOT STEALING) And I just put that info together into one game. Thanks.


Title: Cobra
Post by: Hexadecimal Disaster on December 21, 2002, 03:18:01 PM
Schweet. 'Nuff said.  :D  And some specials are really funny to watch...

...but I still don't get the point behind the super-jumps without air combos...


Title: Cobra
Post by: toonski84 on December 21, 2002, 04:16:05 PM
hex, you got a point.  but it might be good for dodging, or something

i really can't see anything important missing from this demo.  i'll wait until the finished version to play it again, though.


Title: Yeah
Post by: Rokkuman on December 21, 2002, 05:10:18 PM
Yeah,I know, I'll try to add some kind of point to the super jumps.


Title: LooseCaboose.
Post by: Rokkuman on December 21, 2002, 07:57:09 PM
LooseCaboose: I read a previous post you made and it sounds like you're pretty good at making smart AI. Could you please help me on making AI that can defend its self and attack?


Title: Cobra
Post by: toonski84 on December 21, 2002, 08:44:28 PM
from what i understand, fighting game ai is pretty much the character moving back and forth, and choosing an attack depending on the distance.  close: toss medium:punch/kick far:projectile.  etc.  and does those attacks and blocks on random intervals.  but i've never made a fighting game, so i wouldnt know.  i think i might be able to find one with source if you can learn from it.


Title: Thanks
Post by: Rokkuman on December 21, 2002, 08:58:41 PM
Thanks Toonski, i'll try that.

By the way. Were any of the character designs lame, or are there any improvements I should make to anyone. And feel free to post pictures of any character designs you might want in the game. ((And that Moe guy, I need another name for him.))


Title: Cobra
Post by: na_th_an on December 21, 2002, 09:08:53 PM
The chick should look more sexy. Or you should add a sexy girl :P. Every fighting game has a sexy girl ;)


Title: Cobra
Post by: toonski84 on December 22, 2002, 02:14:29 AM
you spanish people and your sexy girls...

maybe make a story, then craft the characters around it?  it worked for x-men  :-?


Title: Feedback
Post by: Rokkuman on December 22, 2002, 02:39:23 AM
A. Nathan: Which chick are you talking about?

B. Has anyone done two player just to have fun with their friends?/Does anyone find the game just plain fun aside from the little effects and goodies added?

C. I need a name for Moe. He just doesn't look like a Moe. Please give me ideas.

D. Stage Ideas?

E. Does it seem too slow? Do you get errors?

F. Other things that you just wanna say?


Title: Cobra
Post by: LooseCaboose on December 22, 2002, 07:14:03 AM
I will be releasing the entire source code, including commented AI for QBDBZ with the final release. My AI is based on a finite state machine with rule based state transitions. For example the computer player may change from the idle state to the attack state if it is on the ground, its opponent is close, has less health and not currently blocking. A simplified version of the code works thusley:
Code:

sub computeAI
 
  select case ai.state
  case IDLE
    '**** Computer is moving back and forth idly ****  
    if ai.onGround and distance < 150 then
      if opponent.state = ATTACK then
        ai.state = BLOCK
      else
        if opponent.state <> BLOCK and opponent.health < ai.health then
          ai.state = ATTACK
        end if
      end if
    end if

  case ATTACK
    '**** Attack state ****

  ....

  end select

end sub
           

You could also try bugging Hex for details about his AI design (I believe his is in a more functional state than mine).


Title: Cobra
Post by: na_th_an on December 22, 2002, 09:30:31 AM
Quote from: "toonski84"
you spanish people and your sexy girls...


Don't you have sexy girls in USA ? :lol:

Maybe "sexy" is not the most suitable word about what I mean. I mean "cute".


Title: Cobra
Post by: toonski84 on December 22, 2002, 10:21:40 AM
well, there certainly could be more, but unless you're gay that applies for just about every nation in the world except switzerland (which has way too many to be greedy :D)


Title: I need your apinyin
Post by: Rokkuman on December 22, 2002, 07:05:24 PM
I added something in Cobra, where if you're knocked into the air, you'll crash and fall backwards off the wall. Should I keep this, or get rid of it.


Title: Cobra
Post by: toonski84 on December 22, 2002, 07:08:05 PM
um, sort of... maybe if you get hit by a projectile.  if you get hit by a punch maybe you just get thrown back.  i remember in the last blade games for the neogeo you could throw a roundhouse kick at someone and they did that, it it looked cool for sure, but you can get hit in the air many, many times in a match, that's all.


Title: Cobra
Post by: Rokkuman on December 22, 2002, 07:22:57 PM
I changed the Topic name of this section. I thought it would be the best because I hadn't heard of all these current projects, and it was at the time where all there were were those silly little stick fighting games with almost no effort put into them. But Sidewalk fighter and Stick Fighters Brawl 2 were the best QB fighting games I had seen at the time.


Title: Cobra
Post by: toonski84 on December 22, 2002, 07:39:01 PM
hey -- anyone remember immortal kombat?  now that was old-school


Title: Cobra
Post by: Rokkuman on December 22, 2002, 07:47:06 PM
Funny... that was the first game that came to mind when I was typing that. Along with blud fite.


Title: Cobra
Post by: toonski84 on December 22, 2002, 07:55:05 PM
yeah, and spherefighter and streetfight.   dammit, i need to clean off some of this crap off my hard drive.

oh, and as for a name for moe, how about kyle?  that came to mind when i saw the dude.


Title: Cobra
Post by: Hexadecimal Disaster on December 22, 2002, 10:13:36 PM
Moe? Curly! Larry! Shemp! There's a lot of names available!  :bounce:

And... remember one thing: first the gameplay, then the fancy effects. Just an advice.  8)


Title: Kyle
Post by: Rokkuman on December 22, 2002, 11:39:28 PM
I went ahead and changed his name to Kyle. That's much better than Moe.


Title: Cobra
Post by: Rokkuman on December 23, 2002, 02:36:57 AM
Come on people, I'm almost out of character ideas, give me some suggestions so I don't make stupid people.


Title: Cobra
Post by: Rokkuman on December 23, 2002, 03:58:55 AM
Okaay. well just so I know. in you guys's opinion. Who was the coolest character on Cobra?


Title: Cobra
Post by: relsoft on December 23, 2002, 04:47:13 AM
Genso!!!!

LOL


Title: Cobra
Post by: Rokkuman on December 23, 2002, 05:49:50 AM
Uhhh... no he's not. :)


Title: Cobra
Post by: Rokkuman on December 26, 2002, 01:03:29 AM
Does anyone have a disliking to the cartoonish graphics at all? Or do you think that it's actually ok as long as the animation is smooth? ((yes, I'm just trying to bring you back to my forum)) :wink:


Title: Cobra
Post by: na_th_an on December 26, 2002, 09:49:05 AM
hehehe

Well, personally I like the cartonish look. My fav. GFX of all time are those in the SFA series. They simply rock.


Title: Cobra
Post by: Piptol on December 26, 2002, 10:15:30 AM
Quote from: "Megaman"
Does anyone have a disliking to the cartoonish graphics at all? Or do you think that it's actually ok as long as the animation is smooth? ((yes, I'm just trying to bring you back to my forum)) :wink:


I must admit, I was impressed when I played it after only having seen the screenshots in this forum. You *really* need a better keyboard handler.. but otherwise keep up the good work :)


Title: Cobra
Post by: na_th_an on December 26, 2002, 02:21:01 PM
Yeah, I'm with Pip. You can use the one you can find here: http://www.geocities.com/aliphax/files.html  -- It is easy to use and works quite well. This is which I am using right now.


Title: Cobra
Post by: toonski84 on December 26, 2002, 03:30:55 PM
right now  you're using inkey$.  great for text input, but way too unresponsive for games.  either use multikey by milo sedlack, or a pure qb multikey using port 60h.  if you want either, ring.


Title: Cobra
Post by: Rokkuman on December 26, 2002, 07:23:40 PM
I want to know about the port 60 one.

Unless it's the one where you can hold it down, but it only detect one key.


Title: Cobra
Post by: na_th_an on December 26, 2002, 07:58:50 PM
The pureQB trick uses a 127 indexes array to store keyboard info. For example, key Enter has scancode # &H1D, so keys%(&H1D) will be -1 (TRUE) if Enter is pressed, otherwise 0 (FALSE).

To do the trick, the array is written inside a loop, for example the vertical retrace loop or your timing loop. Port &H60 is read, and the value returned is set in the array, then the buffer is cleared. In the next loop, a new key will be read from the buffer if you are pressing several.

At the end of the loop, all your multiple keypresses have been read and you just have to check the correct indexes in the array keys%(), for example, keys%(72) to read the "UP" key.

When you've checked all the keypresses, you just put all key%() array indexes to 0, to clear your virtual keyboard handler.

Check this snipped by Eric Carr to understand how it works

Code:
'===========================================================================
' Subject: SIMULTANEOUS KEY DEMO             Date: 03-18-96 (13:12)      
' Author:  Eric Carr                         Code: QB, QBasic, PDS        
' Origin:  FidoNet QUIK_BAS Echo           Packet: KEYBOARD.ABC
'===========================================================================
'Ok..Here is the sample keyboard routine I promised..I haven't tested it on any
'other computer excpet mine, but it should work for anyone..  This program lets
'you move a box around by pressing the arrow keys..The acual routine in only 4
'lines as i have marked..This program requires a minimum of a 486sx 25mhz if
'not compiled to run fast enough for all the keys to be updated..I also
'reprogrammed the internal timer from 18.2 to 30, so I could time it to 30 fps.
'To see if a key is being currently pressed, the variable KS is used (IF
'KS(75)=1 THEN button is pressed). Instead of ASCII, this uses scan codes,
'which you can look at in the QB help..Hope you can understand it! :)

 DEFINT A-Z: DIM B(300): CLS

 N& = 39772                  'Reprogram the timer to 30hz
 LB& = N& AND &HFF           'instead of 18.2 (for 30 frames
 HB& = (N& / 256) AND &HFF   'per second.)
 OUT &H43, &H3C: OUT &H40, LB&: OUT &H40, HB&

 DIM KS(255), SC(255), DU(255)
 FOR E = 0 TO 127      ' Setup key data table KSC()
 SC(E) = E: DU(E) = 1
 NEXT
 FOR E = 128 TO 255
 SC(E) = E - 128: DU(E) = 0
 NEXT

 SCREEN 13: COLOR 4
 LOCATE 10, 3: PRINT "Keyboard input routine by Eric Carr"
 COLOR 7: PRINT : COLOR 2
 PRINT "  Use the arrow keys to move the box."
 PRINT "Note that you can press two or more keys"
 PRINT "    at once for diagnal movement!"
 PRINT : COLOR 8: PRINT "          Press [Esc] to quit"
 X = 150: Y = 100: BX = X: BY = Y
 DEF SEG = 0
 POKE (1132), 0
 GET (X, Y)-(X + 15, Y + 15), B
 DO  'main loop

' __ By NATHAN __ : This is the loop where KS array is
' filled with values depending on the keypresses:

T:
 I$ = INKEY$       ' So the keyb buffer don't get full     \routine/
 I = INP(&H60)     ' Get keyboard scan code from port 60h   \lines/
 OUT &H61, INP(&H61) OR &H82: OUT &H20, &H20       '         \!!!/
 KS(SC(I)) = DU(I) ' This says what keys are pressed          \!/
 
 IF PEEK(1132) < 1 THEN GOTO T  'If not enough time was passed goto T



 POKE (1132), 0  'reset timer again
 BX = X: BY = Y

' __ By NATHAN __ See how we check inside the array for
' keypresses:

 IF KS(75) = 1 THEN XC = XC - 2: IF XC < -15 THEN XC = -15
 IF KS(77) = 1 THEN XC = XC + 2: IF XC > 15 THEN XC = 15
 IF KS(72) = 1 THEN YC = YC - 2: IF YC < -15 THEN YC = -15
 IF KS(80) = 1 THEN YC = YC + 2: IF YC > 15 THEN YC = 15
 IF XC > 0 THEN XC = XC - 1 ELSE IF XC < 0 THEN XC = XC + 1
 IF YC > 0 THEN YC = YC - 1 ELSE IF YC < 0 THEN YC = YC + 1
 Y = Y + YC: X = X + XC
 IF X > 300 THEN X = 300 ELSE IF X < 0 THEN X = 0
 IF Y > 180 THEN Y = 180 ELSE IF Y < 0 THEN Y = 0
 IF X <> BX OR Y <> BY THEN
 WAIT 936, 8: PUT (BX, BY), B, PSET
 GET (X, Y)-(X + 15, Y + 15), B: LINE (X, Y)-(X + 15, Y + 15), 9, BF
 END IF
 LOOP UNTIL KS(1) = 1 'loop until [Esc] (scan code 1) is pressed

 N& = 65535                      'Program the timer back to
 LB& = N& AND &HFF               '18.2hz before exiting!
 HB& = (N& / 256) AND &HFF
 OUT &H43, &H3C: OUT &H40, LB&: OUT &H40, HB&

 OUT &H61, INP(&H61) OR &H82: OUT &H20, &H20
 CLEAR   'need to have this if reprograming the timer
 END      'I think this ends the program. I'm not quite sure.. :)


This code snipped uses timer. Windoze doesn't like that, so maybe you'll like to code a VGA retrace wait loop:

Code:

' Missing initialization code, just line in Carr's routine

' This is the same as WAIT &H3DA,8: WAIT &H3DA,8,8
' Nathan's code, untested but likely to work

' while bit 3 of port 3DAh is 0 do keyboard stuff;
WHILE (INP(&H3DA) AND 8 ) = 0
   ' Put here the ks stuff and so:
   I$ = INKEY$       ' So the keyb buffer don't get full     \routine/
   I = INP(&H60)     ' Get keyboard scan code from port 60h   \lines/
   OUT &H61, INP(&H61) OR &H82: OUT &H20, &H20       '         \!!!/
   KS(SC(I)) = DU(I) ' This says what keys are pressed          \!/
WEND

' while bit 3 of port 3DAh is 1 no opperation;
WHILE (INP(&H3DA) AND 8 ) = 8
WEND


Hope this works :P:P:P:D


Title: Cobra
Post by: toonski84 on December 26, 2002, 08:12:00 PM
here.  what port 60h [inp (&H60)] does is it fires off whenever a key is pressed or released.  this keeps track of the keypresses, and the key releases and stores them into kbd().  scan codes are slightly different than with inkey$, so test some of the keys with this demo

Code:

DIM kbd(140)  AS INTEGER

DEF SEG = &H40: POKE &H1C, PEEK(&H1A): POKE &H17, PEEK(&H17) AND NOT 32
'frames loop
DO
    'keyboard input
    K% = INP(&H60): kbd(K% AND 127) = -((K% AND 128) = 0)
    DEF SEG = &H40: POKE &H1C, PEEK(&H1A)
    IF kbd(1) THEN EXIT DO

    LOCATE 1, 40: PRINT K%
    LOCATE 1, 1
    FOR i = 0 TO 19
     PRINT kbd%(i); "  ";
     PRINT kbd%(i + 20); "  ";
     PRINT kbd%(i + 40); "  ";
     PRINT kbd%(i + 60); "  ";
     PRINT kbd%(i + 80); "  ";
     PRINT kbd%(i + 100); "  ";
     PRINT kbd%(i + 120); "  "
    NEXT
LOOP



Title: Cobra
Post by: toonski84 on December 26, 2002, 08:14:15 PM
gash dernit, nate, ya beat me to it!  :evil:  :evil:  :evil:

oh well.  i should mention i got the core code for above demo from an antoni gual raycaster.


Title: Cobra
Post by: na_th_an on December 26, 2002, 10:40:19 PM
Our codes do the same in different manners, but I think yours is way better.


Title: Cobra
Post by: toonski84 on December 26, 2002, 10:51:45 PM
good point.  just check and clear the buffer...

y'know, i've been finding more and more useful "pure" qb alternatives to libs.  first seav's timer, now antoni's multikey, really the only thing worth getting a lib for is multimedia (sound and graphics)...  i'm kinda glad cosmox lets you build the objs yourself...


Title: Cobra
Post by: na_th_an on December 26, 2002, 10:59:31 PM
Yeah, the best thing is to build up your own lib peeking here and there.

About PQB alternatives, QMIDI 4.1 and DMAPlay work good together and give a good sound engine, if MIDI music and 1 channel digital sound are enough for you :P


Title: Cobra
Post by: toonski84 on December 26, 2002, 11:35:35 PM
i always thought qmidi was a qlb... hmm..  then i wonder why i didnt use it before... *shrugs*.   i hear the subshock team, whenever they are rescued from their cryogenic status are producing a pure qb mod player suitable for games.  that oughta be interesting... and hey, remember mk jamz?


Title: Cobra
Post by: na_th_an on December 26, 2002, 11:54:52 PM
Nope, What's that?

About Qmidi... Yeah, you have seen the QLB version, but Jesse Dorland made that one in pure QB first, then someone compiled it into a QLB. I think you can find it in the alypha URL I gave before in this same thread.


Title: Cobra
Post by: toonski84 on December 27, 2002, 10:58:49 AM
*nods*  i would prefer some of the bigger libs (ds4qb, bwswb[sp?]) if  you could compartmentalize them.


Title: Cobra
Post by: na_th_an on December 27, 2002, 03:18:08 PM
My problem with DS4QB is the huge lag (I have a slow compter) and that it takes so many resources. I have to stick with DOS lil'libs.

Anyhow, I never got BWSB to work... Can you give me some help?


Title: Cobra
Post by: toonski84 on December 27, 2002, 06:15:14 PM
i wish i could help you.  the only sound i've ever used in my programs is mk jamz and that one-sub wave player.


Title: Cobra
Post by: na_th_an on December 27, 2002, 06:45:59 PM
What's mk jamz? Maybe it fits in my outcoming simple ASCII game project.


Title: Cobra
Post by: toonski84 on December 27, 2002, 07:48:33 PM
remember the old days of molnar/kalcutta?  they made a music program that used the fm synthesizer that could play in the background called mk jamz if you looped it at a decent rate.


Title: Cobra
Post by: na_th_an on December 27, 2002, 08:30:49 PM
Aha, FM music. It is cool, I once made a crappy FM tracker... Maybe I'll upload it to our web (WOPR2K) when we finish it :P


Title: Cobra
Post by: toonski84 on December 27, 2002, 09:10:32 PM
yeah, and check out mk jamz, too.  i had a lot of fun with it when i was 12 :)


Title: Cobra
Post by: Rokkuman on December 27, 2002, 09:14:50 PM
Aren't they the ones that made "Ambush at South Range?"


Title: Cobra
Post by: toonski84 on December 27, 2002, 09:16:48 PM
yeah, they made a bunch of stupid games, like that and 'bob sagat killer'.  the music program was really the only thing from them that was ever really good.  i'm surprised you remember that proggy game, it was old and wasnt memorable in any way, shape or form...


Title: Cobra
Post by: Rokkuman on December 27, 2002, 09:39:22 PM
Heck, I LOVED Ambush at South Range 2.


Title: Cobra
Post by: na_th_an on December 28, 2002, 12:00:30 AM
Wow man!! I made a google search and I got 1 entry. The link still works: http://www.fortunecity.de/lindenpark/heiner/541/program/sound/mkjams.zip

Better grab it disappears!!

And the ol'PQB VOC player is this one:

Code:
'
' DMA functions were written by Mike Huff
'
' VOC file has to be Mono, 8bit, any freq.
'
'  Another note: Some sound cards can't play .WAV's over 22050 with
'                these functions.
'
'
DECLARE SUB PlayFile (WavFileName$, WavFreq&)
DECLARE FUNCTION FileLength& (WavFileName$)
DECLARE FUNCTION DMADone% ()
DECLARE FUNCTION ResetDSP% ()
DECLARE SUB MasterVolume (Right%, Left%, Getvol%)
DECLARE SUB WriteDSP (byte%)
DECLARE FUNCTION ReadDSP% ()
DECLARE SUB SpeakerState (OnOff%)
DECLARE SUB DMAPlay (Segment&, Offset&, Length&, Freq&)
DECLARE FUNCTION GetBLASTER% (DMA%, BasePort%, IRQ%)
DECLARE FUNCTION DSPVersion! ()
'-----COMMONs-----
  COMMON SHARED PlaySndFlag%, WavFlag%
  COMMON SHARED BasePort%, LenPort%, Channel%, IRQ%, HaveBlast%, WavRep%, TheWavLen&
  COMMON SHARED TFWav() AS STRING * 32767
'-----End COMMONs-----
ON ERROR GOTO EHandler
CLS

 '$DYNAMIC
  DIM SHARED TFWav(1) AS STRING * 32767
   
'This detects the SB and does some other initializations:

    HaveBlast% = GetBLASTER(Channel%, BasePort%, IRQ%)' Parses BLASTER environment
      IF HaveBlast% THEN PlaySndFlag% = 1 ELSE PlaySndFlag% = 0
     ResetIt% = ResetDSP%
     SpeakerState 1 'turn the speaker on
     MasterVolume 15, 15, 0 'this cranks the master volume all the way up.

'End initialization stuff here

Freq& = 11025                    '<-- Type in the frequency here

FileName$ = "IAMONE.VOC"  ' <-- VOC / WAV file

PlayFile FileName$, Freq&

 DO
  COLOR INT(RND * 16)
  PRINT "Playing sound in background! Yeehaw!"
 LOOP UNTIL DMADone% <> 0

COLOR 15
PRINT "Finished!"
END


EHandler:
COLOR 15
Er% = ERR
PRINT "Something bad happened!"
PRINT "Error code: "; Er%
END
RESUME

REM $STATIC
FUNCTION DMADone%
Count% = INP(LenPort%)
Count2% = INP(LenPort%)
Count& = CLNG(Count% + 1) * CLNG(Count2% + 1)
IF (Count& - 1) >= &HFFFF& THEN junk% = INP(DSPDataAvail%): DMADone% = -1
END FUNCTION

SUB DMAPlay (Segment&, Offset&, Length&, Freq&)
' Transfers and plays the contents of the buffer.
IF PlaySndFlag% = 0 THEN EXIT SUB
Length& = Length& - 1
Page% = 0
MemLoc& = Segment& * 16 + Offset&
SELECT CASE Channel%
    CASE 0
       PgPort% = &H87
       AddPort% = &H0
       LenPort% = &H1
       ModeReg% = &H48
    CASE 1
       PgPort% = &H83
       AddPort% = &H2
       LenPort% = &H3
       ModeReg% = &H49
    CASE 2
       PgPort% = &H81
       AddPort% = &H4
       LenPort% = &H5
       ModeReg% = &H4A
    CASE 3
       PgPort% = &H82
       AddPort% = &H6
       LenPort% = &H7
       ModeReg% = &H4B
    CASE ELSE
       EXIT SUB
END SELECT

OUT &HA, &H4 + Channel%
OUT &HC, &H0
OUT &HB, ModeReg%
OUT AddPort%, MemLoc& AND &HFF
OUT AddPort%, (MemLoc& AND &HFFFF&) \ &H100
IF (MemLoc& AND 65536) THEN Page% = Page% + 1
IF (MemLoc& AND 131072) THEN Page% = Page% + 2
IF (MemLoc& AND 262144) THEN Page% = Page% + 4
IF (MemLoc& AND 524288) THEN Page% = Page% + 8
OUT PgPort%, Page%
OUT LenPort%, Length& AND &HFF
OUT LenPort%, (Length& AND &HFFFF&) \ &H100
OUT &HA, Channel%

IF Freq& < 23000 THEN
   TimeConst% = 256 - 1000000 \ Freq&
   WriteDSP &H40
   WriteDSP TimeConst%
   WriteDSP &H14
   WriteDSP (Length& AND &HFF)
   WriteDSP ((Length& AND &HFFFF&) \ &H100)
ELSE
   IF DSPVersion! >= 3 THEN
      TimeConst% = ((65536 - 256000000 \ Freq&) AND &HFFFF&) \ &H100
      WriteDSP &H40
      WriteDSP TimeConst%
      WriteDSP (Length& AND &HFF)
      WriteDSP ((Length& AND &HFFFF&) \ &H100)
      WriteDSP &H91
   ELSE
      PRINT "You need a Sound Blaster with a DSP v3.x+ to play at high speed."
      EXIT SUB
   END IF
END IF
END SUB

SUB DoSNDEvent (SNDNum%)
 SELECT CASE SNDNum%
  CASE 1
 END SELECT
END SUB

FUNCTION DSPVersion!
' Gets the DSP version.
WriteDSP &HE1
Temp% = ReadDSP%
Temp2% = ReadDSP%
DSPVersion! = VAL(STR$(Temp%) + "." + STR$(Temp2%))
END FUNCTION

FUNCTION FileLength& (WavFileName$)
 OPEN WavFileName$ FOR BINARY AS #1
  TotWavLength& = LOF(1) - 44
  ResWavLength& = TotWavLength& - (32767& * WavRep%) - 44
  IF ResWavLength& > 32767& THEN ResWavLength& = 32767&
 CLOSE #1
IF ResWavLength& = 0 THEN KILL ResWavFileName$
FileLength& = ResWavLength&
END FUNCTION

FUNCTION GetBLASTER% (DMA%, BasePort%, IRQ%)
' This subroutine parses the BLASTER environment string and returns settings.
IF LEN(ENVIRON$("BLASTER")) = 0 THEN GetBLASTER% = 0: EXIT FUNCTION
FOR Length% = 1 TO LEN(ENVIRON$("BLASTER"))
   SELECT CASE MID$(ENVIRON$("BLASTER"), Length%, 1)
      CASE "A"
        BasePort% = VAL("&H" + MID$(ENVIRON$("BLASTER"), Length% + 1, 3))
      CASE "I"
        IRQ% = VAL(MID$(ENVIRON$("BLASTER"), Length% + 1, 1))
      CASE "D"
        DMA% = VAL(MID$(ENVIRON$("BLASTER"), Length% + 1, 1))
   END SELECT
NEXT
GetBLASTER% = 1
END FUNCTION

SUB MakeWav

WavLen1& = FileLength("tfwav1.wav")
WavLen1& = WavLen1& + 44
 OPEN "tfwav1.wav" FOR BINARY AS #1
  GET #1, 0, TFWav(1) 'Get 32k from file (skip header on WAV)
 CLOSE #1
 OPEN "tfall.wav" FOR BINARY AS #1
  PUT #1, 0, TFWav(1)
 CLOSE #1

END SUB

SUB MasterVolume (Right%, Left%, Getvol%)
OUT BasePort% + 4, &H22
'PRINT BasePort%
IF Getvol% THEN
   Left% = INP(BasePort% + 5) \ 16
   Right% = INP(BasePort% + 5) AND &HF
   EXIT SUB
ELSE
   OUT BasePort% + 5, (Right% + Left% * 16) AND &HFF
END IF
END SUB

SUB PlayFile (WavFileName$, WavFreq&)
 WavRep% = 0
 WavFlag% = 1
 TheWavLen& = FileLength(WavFileName$)
 OPEN WavFileName$ FOR BINARY AS #1
  GET #1, 44, TFWav(1) 'Get 32k from file (skip header on WAV)
 CLOSE #1
 'TheWavLen& = TheWavLen& - 44
 DMAPlay VARSEG(TFWav(1)), VARPTR(TFWav(1)), TheWavLen&, WavFreq&
END SUB

FUNCTION ReadDSP%
' Reads a byte from the DSP
DO
LOOP UNTIL INP(BasePort% + 14) AND &H80
ReadDSP% = INP(BasePort% + 10)
END FUNCTION

FUNCTION ResetDSP%
' Resets the DSP
OUT BasePort% + 6, 1
FOR Count% = 1 TO 4
   junk% = INP(BasePort% + 6)
NEXT
OUT BasePort% + 6, 0
IF INP(BasePort% + 14) AND &H80 = &H80 AND INP(BasePort% + 10) = &HAA THEN
   ResetDSP% = -1
ELSE
   ResetDSP% = 0
END IF
END FUNCTION

SUB SpeakerState (OnOff%)
' Turns speaker on or off.
IF OnOff% THEN WriteDSP &HD1 ELSE WriteDSP &HD3
END SUB

SUB WriteDSP (byte%)
' Writes a byte to the DSP
DO
LOOP WHILE INP(BasePort% + 12) AND &H80
OUT BasePort% + 12, byte%
END SUB



Neat snippet :P I patched this to make it run better. With WAVs, it produces some noise at the end 'cause most wave editor append info in wav files. The best thing you can do is use the VOC format. You can download Cool Edit 96 here (http://www.realjuggalos.com/icp/remixes/how2be.html) (shareware version) and register it (don't ask me how and read the text in the webpage I linked ;) ) to make the conversions.

CE96 is a good choice if you don't have any sound editing tool and you only need it to cut, trim and convert waves.


Title: Cobra
Post by: toonski84 on December 28, 2002, 01:21:47 AM
yeah, in wormer i used somebody's wave player that was one sub and only played 11k mono wav files.  it's crappy, crappy quality but it was easy as heck.  but that's just me, i'll probably buy my wedding ring 3 days before the wedding and return it after so i dont have to pay anything.  i've used dmaplay before, though, and it's probably the best pure qb option for wave files.  anybody still have that code that stored wave files into ems and played them from memory?


Title: Cobra
Post by: na_th_an on December 28, 2002, 09:43:40 AM
Urm, never used that EMS code, but may be able to find it. I have megs and megs of ABC snippets.


Title: Cobra
Post by: Rokkuman on January 06, 2003, 11:34:54 PM
Man. I can't figure out how to add this keyhandler. Every time I try your character is able to walk out of a midair jump. Hopefully I'll figure this out. But let me ask you this, just because if you say yes doesn't mean I'll just stop, but let's say I did decide to stick with this keyhandler. Would you. (A. Play it normally. (B. Play it but wish it were better. or (C. Avoid it like the plague and flame me like mad.


Title: Cobra
Post by: toonski84 on January 06, 2003, 11:38:58 PM
that isnt the keyhandlers fault.  lemme see the code where you read a key and do an action.  left and right should only walk left and right if the person is touching the ground.  and if...then clause should take care of that.


Title: Cobra
Post by: Rokkuman on January 06, 2003, 11:50:01 PM
Sorry, the walking code is spread among a lot of different subs. You would *not* understand it, I hardly can.


Title: Cobra
Post by: toonski84 on January 06, 2003, 11:53:21 PM
then perhaps you need to rewrite it.  maybe something a little orgainized.  spagetti code is not healthy...

but lemme see the code anyway.  i'll see what i can do with it.


Title: Cobra
Post by: Dav on January 07, 2003, 12:10:45 AM
The GetBLASTER% function in the code up there needs tweaking a little.  Sometimes the IRQ is set to 10 on systems (mine is one of them) and the MID$ up there is only grabbing 1 byte after the I, failing to get the 10.  

- Dav


Title: Cobra
Post by: Rokkuman on January 07, 2003, 11:39:46 PM
Ok, do you guys think I should rewrite Cobra? I mean, sure it will add on to the release date, but then I can take more of your ideas into account and improve on what I did. I won't delete the original copy, and all your "favorite Qb characters" will still be in the game. But by redoing it, I can make it better. So waddya say?


Title: Cobra
Post by: toonski84 on January 07, 2003, 11:48:02 PM
do it.  with some proper coding techniques, it could be a lot more efiicient.

and since you're redesigning it, dont be so reluctant to use a library.  they are not "someone else's code", they are replacements for mediocre qb functions, such as put.  and ugl's memory management works like a dream.  the most technilogically advanced programmers today use libraries like directx and opengl to render high-quality graphics, there's no shame in and the "challenge" will only keep you from making a great game.


Title: Cobra
Post by: Rokkuman on January 07, 2003, 11:51:39 PM
Oh I know, I developed my drawing functions and other things. I'm gonna stick with programming this libless. But it will be library qua- it will be good!

So? Anybody gots any non-EMS memory conserving tips? I could use all of them.


Title: Cobra
Post by: Rokkuman on January 08, 2003, 12:06:48 AM
Hey, thanks to whoever it was that said something about the live actors and the video recorders for Garou, ((in that KOF post)) I just got an idea, I can make stick figures first, and then just draw the sprites over them! That should get rid of my animation laziness and people will look better and possibly more fluid! Thanks poster in the KOF topic area!


Title: Cobra
Post by: toonski84 on January 08, 2003, 12:46:47 AM
ah, nuts.  dont do that, it wont look as good.  have you read tsugamo's tutorial on fighting game sprites?  pixel-shifting makes it a LOT easier.


Title: Cobra
Post by: Rokkuman on January 08, 2003, 02:33:17 AM
Yeah, I've read it, maybe I should look over it again.

EDIT But actually... I'll just finish this version, I don't know what's gonna happen with the keyhandler, but I'm telling you guys, I'm really trying to get it in, but it keeps countering with other parts of the engine. But if it will make you all happy I'll keep trying until it takes me abselutely too long or I just can't add it. But I'll finish this. As Vance told me: Street Fighter One was pathetic but then Street Fighter 2 had become one of the best fighting games in history.


Title: Cobra
Post by: citpes on January 08, 2003, 03:13:46 PM
im willing to put my life savings, about 2$, on the fact that you have learnt a hell of a lot while coding cobra!?  imo, you should finish it, release it and see what comments come out.  then set out to improve it based on comments and critsims by implementing the things that you have learnt!

I know that every time i start to code something i learn that there is a easier way to do it, but by that time it's too late to put in!  all i can do is use it next time!


Title: Cobra
Post by: toonski84 on January 08, 2003, 06:43:13 PM
haha... street fighter one was a riot.  they had this so-called 'innovative' system where there was just one big rubber button for punching and kicking, and however hard you hit it, your character would make a resulting l/m/h.  special moves were almost impossible to land, so if you got hit, it would take off nearly a third of the other guys life.  also, you couldnt choose characters.  if you picked first player, you were ryu, second you were ken (which is why they're clones of each other).  so you were either a goofy-looking redhead in a white costume or a goofy looking blond in a red costume.


Title: Cobra
Post by: Rokkuman on January 10, 2003, 12:01:10 AM
So again, BESIDES THE KEYHANDLER what else did everyone find annoying about Cobra. ((yes I am working on the Character Select Screen))


Title: Cobra
Post by: Rokkuman on January 19, 2003, 05:48:25 AM
Cobra's demo is nearing completion. All I need to do so far is work on a few stages. I would just like to know if anyone found that much of anything was missing. Here are some things that have been finished since that demo you played.

-Finished Stuff
*Matches end and go back to character select screen    

*Everyone's moves were completed, and one character has    
been added
   
 *Those disgusting mug-shots were redone, though some may      have mixed feelings about them, I thing they look better than those zombieish ones.

*Some animations were redone. Moe's name was changed to Kyle.

*People will bounce off walls if hit hard enough

*Particle effects were added

*Some AI was added, though it's still kind of stupid

------------------------------------------------------------------------------
-Stuff that still needs to be added

*Need more stages

*PC speaker sounds,((sound blaster ain't happening, but if it's really annoying, there will be a sound off option))

*Finish all characters, I'll either aim for ten or fifteen(not including boss and secret characters

*Make movelists

*Character select screen needs BIG help

*Story mode needs to progress through enemies and I need to add storylines to characters.

*AI needs BIG help sort of

----------------------------------------------------------------
-Things that I *might* add

*I've been planning to make it to where you can get knocked off the levels either onto different levels (Dead or Alive), or to your death (Killer Instinct).

*I might make it to where when you hit the ground too hard you'll see a crater on the ground. It would be a neat effect.

*I'm still thinking on QB Cameos, so Nathan, Jill just *might* make it. :) She can't have many references to how she is in her original game or my dad will blow me up with a spoon!

*Different modes of play might be available. Story mode will most likely have little parts where they will talk to each other before fighting.

*That keyhandler *might* make it in there.

*A sequal might be made, but I'll wait till I get some response on this version.

---------------------
Well, I'll be glad to accept any comments. If I have something there you don't want, or something I don't have that you do want, feel free to tell me. And don't say anytjhing to me about the keyhandler. I'm trying people! :)+


Title: Cobra
Post by: na_th_an on January 19, 2003, 10:58:29 AM
Quote from: "Megaman"
*I'm still thinking on QB Cameos, so Nathan, Jill just *might* make it. :) She can't have many references to how she is in her original game or my dad will blow me up with a spoon!


HEHEHHEHE :D:D:D:D:D:D:D Anyhow, I posted the sprites in this thread, I think.


Title: Cobra
Post by: ak00ma on January 27, 2003, 03:23:21 PM
How do you do the backgrounds?? Do you use simple QB draw commands or do you load drawn images from other programs into the game???


Title: Cobra
Post by: toonski84 on January 27, 2003, 08:41:16 PM
i imagine draw commands, and page flipping.  but that's an uneducated guess.


Title: Cobra
Post by: Rokkuman on January 28, 2003, 12:11:23 AM
I made a stage editor that makes stages out of lines and circles.So I do use lines and stuff, but not straight out of QB.]

By the way, you're all free to post stage ideas and stuff, they can't be *too*detailed. (cans on the ground) because that just slows the level down more, although one or two would be fine.

EDIT: Sorry, I just had to try this somewhere
Quote from: "1"

Quote from: "2"

Quote from: "3"

Quote from: "4"

Quote from: "5"

Quote from: "6"

Quote from: "7"

Quote from: "8"

Quote from: "9"

Quote from: "10"

Quote from: "11"

Quote from: "12"

Quote from: "13"
WOW THIS IS COOL!
Quote from: "14"

Quote from: "15"

Quote from: "16"

Quote from: "17"

Quote from: "18"





Title: Cobra
Post by: Rokkuman on February 24, 2003, 03:08:03 AM
UPDATES ON COBRA------

For those of you that played the Cobra demo, I fixed some of the collision detection. I'm surprised no one noticed them and reported them, but I ignored them for so long, that I forgot them and it all seemed like part of the game. You can also no longer walk through your opponent. Unless both of you are walking into each other, but think of it as a tactic... it really is...

I have added that one girl that I drew a picture of and posted. Her name is Janne and I still need to give her moves and a winpose.

I would like to have one more QB character be in the game, preferrably a popular one that doesn't have any more games being developed for them (doesn't really narrow it down that much).

I ALSO HAVE A SUGGESTION FROM YOU GUYS:[/b] If any of you noticed that ANY of the animations looked awkward, or had misplaced pixels, ect. please let me know to I can touch it up some.

That's about it, there might've been more, but I don't think I left anything out. I am currently working on characters and stages.

EDIT: Oh, by the way, if you were wondering, I tried to add parralax scrolling, but I soon painfully realized that line and paint commands to not overlap very niceley...


Title: Cobra
Post by: Rokkuman on April 20, 2003, 03:22:03 AM
Ok everyone, I am now glad to say (sort of) that trying to get Cobra with a compatible keyhandler has now become my first priority. One of the only problems I'm having is that with Toonski's example of a good keyhandler (page 5 or 4), when I press a key and then let go, the "nothing key" number is different each time I press something, for example, I hold left down, it says 75, I let it go, it says 203, I hold right down, it says 77, I let right go, it now says 205, why is the "nothing key" different and how can I make it stay put?


Title: Cobra
Post by: na_th_an on April 20, 2003, 07:31:41 AM
Why do you need to know that nothing key?  :???:


Title: Cobra
Post by: Piptol on April 20, 2003, 11:15:08 AM
Quote from: "Megaman"
Ok everyone, I am now glad to say (sort of) that trying to get Cobra with a compatible keyhandler has now become my first priority. One of the only problems I'm having is that with Toonski's example of a good keyhandler (page 5 or 4), when I press a key and then let go, the "nothing key" number is different each time I press something, for example, I hold left down, it says 75, I let it go, it says 203, I hold right down, it says 77, I let right go, it now says 205, why is the "nothing key" different and how can I make it stay put?


Nothing key? Looks like a key release code so you can tell when a key is no longer depressed. Rather than check for that, why not just check for the keypresses you want (75, 77 etc)?

PS, this has to be the oldest longest-running thread at QBN for some time..


Title: Cobra
Post by: na_th_an on April 20, 2003, 12:35:06 PM
Yeah. you don't need to care about that depression value. Just check and work with they keypress scancode.


Title: Cobra
Post by: toonski84 on April 20, 2003, 02:27:52 PM
it dont matter what the "nothing" key is... just when it changes, release or derelease the key specified.

of course, a better idea would be to use an assembly keyhandler that properly uses interrupt vectors and is more efficient (like, say, milo's or one of the many fine library keyhandlers out there).


Title: Cobra
Post by: Rokkuman on April 26, 2003, 02:59:06 AM
LEVEL UP

COBRA HAS GAINED:
      AN ACCEPTABLE KEYHANDLER
      86057806540698 XP

[/b]


Title: Cobra
Post by: Ninkazu on April 26, 2003, 12:25:56 PM
Quote from: "Megaman"
LEVEL UP

COBRA HAS GAINED:
      AN ACCEPTABLE KEYHANDLER
      86057806540698 XP

[/b]


Hehehe, very clever. :lol:


Title: Cobra
Post by: Blitz on April 26, 2003, 03:26:15 PM
fuck man, i'm so tired of hearing libless, no lib, pure qb. I understand someone not wanting to use anyone elses code. But for gods sake, there are somethings you can't and shouldn't do in qb. It's code generation is to clumsy and too much crap. And some things you simple can't do in it. You don't want to use anyones code, that's perfectly fine.

But for fucks sake, do it in C or Assembly. Or even pascal if you like. But do not do lame things as storing the binary code in strings and calling it with call absolute. Or using poke and peek when it's clearly not enough. Why are you limiting yourself? Is it anyless of value or anyless your code if some parts are written in C or asm ?

Snap out it.


Title: Cobra
Post by: Ninkazu on April 26, 2003, 03:48:16 PM
Quote from: "Blitz"
f**k man, i'm so tired of hearing libless, no lib, pure qb. I understand someone not wanting to use anyone elses code. But for gods sake, there are somethings you can't and shouldn't do in qb. It's code generation is to clumsy and too much crap. And some things you simple can't do in it. You don't want to use anyones code, that's perfectly fine.

But for f**k sake, do it in C or Assembly. Or even pascal if you like. But do not do lame things as storing the binary code in strings and calling it with call absolute. Or using poke and peek when it's clearly not enough. Why are you limiting yourself? Is it anyless of value or anyless your code if some parts are written in C or asm ?

Snap out it.


It's fun. :king:


Title: Cobra
Post by: Agamemnus on April 26, 2003, 03:54:41 PM
Quote
Snap out it.


At this time I would like to make a plug about a new language I am designing.

Syntax will be similar to BASIC but changeable to C by using a bunch of clever macros.

There will be only three basic functions in the most basic layer: the IF statement, a code jump, and a variable set.

Functions will be redefinable and function syntax will be definable as well, globally for all the functions or locally for just that function. (as in #2)

It will be a clean and fast language that will translate to a compare, jump, and set. Extra native built-in speed-up functions will be extrapolated.

It will be able to have endless depths of variable tables but will be able to call all the variables. (j at depth 1, j at depth 2, and j at depth 3!)

 
It will be called.....



GPL (Global Programming Language)


Title: Cobra
Post by: Rokkuman on April 26, 2003, 04:03:53 PM
Oh good Lord, here he goes again... :-?

Ok, first of all, I don't know where the heck this came from... Nobody was talking about anyone's programming style, this was just a topic about how my game is comming along. I would appreciate if this topic wasn't locked because someone brought up an old, old, old, old, complaint about PureQB vs. Libs, because there is still alot that I plan to post into this...

Yes, for crying our friggin loud, WE ALL KNOW THAT LIBS AND ASSEMBLY AND C AND ALL THAT OTHER GOOD CRAP IS FASTER THAN QB, I know that QB is a super slow language, I can see that from many other commercial games, look at Cobra, then look at Marvel Vs Capcom 2, I think I can look at that and say to myself, "Hmmm.... I'm starting to think that whatever they used is probably somwhat faster than QB."

I don't program in QB to make the best games in the world, I program in it because I want to make the best games with the limits I have, so it's a cool Challenge. That's why I'd rather play a new QB Game, than a new Commercial game,(unless it happens to be an exception). When I do feel like making a super powerful QB Game, then I will use libs and C and all that other crap. But that's not my goal right now... Right now... it's to see how good I can do with what I have...


SO PLEASE BLITZ!!! LEAVE ME ALONE WITH YOUR ANTI PUREQB ARGUMENTS FOR CYRING OUT LOUD!!![/u][/size]

Now hopefully I've gotten my point across and this thread can just continue?


Title: Cobra
Post by: Blitz on April 26, 2003, 05:14:57 PM
Nah, i don't get you. What's so leet about not using a lib? I mean, what are you gaining? Does not use a lib you wrote youself make you a more skilled coder?

Apparently, this seems to be the general opnion. Do not use a lib, even if it's your own. Cuz using a lib would just be plain lame.

C'mon. What's the point? What are you trying to prove? The only thing that it shows is that you still haven't understood what programming is.

I'm sure allot of kids in this forum think my rant is BS, but you'll understand once you start to do some real programming. If you ever will. Please go to a C forum, any c forum telling them about your opnions and you'll see what flaming really is.


Title: Cobra
Post by: Rokkuman on April 26, 2003, 05:21:10 PM
Ok Blitz, look all over QBasic news, and I want you to quote the exact sentece from me, saying that I am against libs.

NOW !!!


Title: Cobra
Post by: Blitz on April 26, 2003, 05:40:51 PM
Allright dude, whatever. Actions say more then words. I've already said what i've wanted. Anymore and i'd just be repeating myself. I'm finished with this.


Title: Cobra
Post by: Rokkuman on April 26, 2003, 05:50:48 PM
Good, be quiet.
_____________________________________________________

Well, the only thing wrong with the keyhandler is that sometimes, QB thinks that the button is still pressed, even when it's not, causing the player to keep walking left, it only happens seldom through the fight though...


Title: Cobra
Post by: momoguru on April 26, 2003, 08:58:27 PM
i look at it like this...

programming in qb is like building a model ship in a bottle... its an ancient hobby, it takes more time to complete something even halfway decent and the tools for the job are very limited.

however... its an art form

sure you can cut the bottle in half to make it easier, yeah..you can 'pre assemble' large chunks of the ship before sliding it in. but in my opinion, why program in a 20 year old language only to use newer technologies to make it easier or better?

i enjoy pure qb, if i wanna make something outside of the scope of qb' abilities, then i don't use qb. id rather not inject my code with steriods, and it sound like ur having a roid rage spasm blitz :)


Title: Cobra
Post by: wizardlife on April 26, 2003, 10:58:32 PM
Quote from: "momoguru"
i look at it like this...

programming in qb is like building a model ship in a bottle... its an ancient hobby, it takes more time to complete something even halfway decent and the tools for the job are very limited.

however... its an art form

sure you can cut the bottle in half to make it easier, yeah..you can 'pre assemble' large chunks of the ship before sliding it in. but in my opinion, why program in a 20 year old language only to use newer technologies to make it easier or better?

i enjoy pure qb, if i wanna make something outside of the scope of qb' abilities, then i don't use qb. id rather not inject my code with steriods, and it sound like ur having a roid rage spasm blitz :)


I agree 100%. An excellent metaphor for the process. I still don't think Blitz will understand it or agree with it... but you've stated it very well. I use QB for quickie things, for pureQB projects to 'prove it can be done' and nothing else. If I'm using assembler, I'll use a compiler that supports it inline, thank you.


Title: Cobra
Post by: LooseCaboose on April 28, 2003, 12:52:42 AM
Quote

f**k man, i'm so tired of hearing libless, no lib, pure qb. I understand someone not wanting to use anyone elses code. But for gods sake, there are somethings you can't and shouldn't do in qb. It's code generation is to clumsy and too much crap. And some things you simple can't do in it. You don't want to use anyones code, that's perfectly fine.

But for f**k sake, do it in C or Assembly. Or even pascal if you like. But do not do lame things as storing the binary code in strings and calling it with call absolute. Or using poke and peek when it's clearly not enough. Why are you limiting yourself? Is it anyless of value or anyless your code if some parts are written in C or asm ?

Pot this is kettle, kettle meet pot.

One could easily say that writting a blitter for a 486 without a modern graphics card in assembly code, when modern cards have builtin blitters and DirectX/OpenGL provide API functions that do the job perfectly fine. Perhaps your reasons for doing this are for the fun or challenge of it, not too disimilar to Megaman's reasons for coding in pureQB.

IMHO assembler is hardly worth learning these days unless you plan to do low level system or embedded programming. There are plenty of high class libraries and code already available for most functions, and many of these libraries arent even written in asembley either (For example, the standard C library is written in C in many implementations).

Quit getting arogant and nasty to people because you think you are a better programmer than they are. Everybody here is learning, some are futher ahead than others.

Quote

It will be called.... GPL (Global Programming Language)

Not to be confused with the GPL (GNU Public License) of course.

Quote

Syntax will be similar to BASIC but changeable to C by using a bunch of clever macros.

Do you mean that your language will have a preprocessor. Remember that C has very good reasons for having a preprocessor and macros, think why Java (which is based on C) doenst have one. Your language sounds interesting, but Im not sure I understand how it will be useful compared to other languages.  

Megaman, sorry for continuing the off-topic trend in this thread (perhaps we need a rant forum wildcard?). Keep up the awesome work with Cobra and dont worry about the whole libs argument, code Cobra without them if you want, just dont get the mindset that libs are evil (I dont think you have though).


Title: Cobra
Post by: relsoft on April 28, 2003, 07:09:55 AM
"if it's fun to  learn, then learn it. If it's not... who the hell would learn a 'not-so-fun' lang?"

ASM is fun dude.


Title: Cobra
Post by: toonski84 on April 28, 2003, 08:22:34 AM
Sheeeesh.  You ignore one thread because it got too damn long and look what happens.

Megaman: For christ-sakes, use a new thread once and awhile.

Others:  So the man doesnt want to use conventional or efficient programming practices.  It's not like you're making the game.  Live and let use spaghetti code on an ancient language, that's what I say.


Title: Cobra
Post by: relsoft on April 29, 2003, 12:39:06 AM
Well, portability wise, my routines are useable with lil modifications in *both* C and Pascal. :*) (Ask Wiz)

I mean, emulators(good ones) are made in mixed languages. Like C+ASM , Pascal+ASM but never Pascal+C.

Assembly survived because of the many things it can do very fast that most compilers now just don't have. ie the sharps #.

And with a compiler such as Delphi and VC++, it's easier to add asm statements in code using the asm statements. An you don't even have to do hard stuff when doing that.  ie no Es:[Di] but

set active device context(Ds surfaces)
The write to [Edi], even DX progs use ASM. look at the amazing DX water simulation at gamedev.net. I saw the source(It can be optimized since he use lots of push) but even then it ran on my cyrix at full speed. That considering it uses a per pixel ATN for refraction.

I rest my case.


Title: Cobra
Post by: LooseCaboose on April 29, 2003, 01:46:51 AM
Quote

Well, portability wise, my routines are useable with lil modifications in *both* C and Pascal. :*) (Ask Wiz)

Thats only one side of portability. Try and get any of your asm code running on Linux or Solaris (even on the x86 line) and you will have to make substantial rewrites. Try to get your asm code running on a different architecture (such as a sparc or mac) and you will be starting from scratch. The C code I posted for the blitter challenge could be easily modified to work with many different operating systems and architectures.

Quote

Assembly survived because of the many things it can do very fast that most compilers now just don't have. ie the sharps #.  

Im assuming you are talking about C# and J# which were never intended to compile fast native code. C# in particular is a .NET language an is primarly aimed at creating byte code which runs in the .NET interpretter (similar to Java).

C and C++ on the other hand are capable of doing just about everything that can be done in assembler (there are some exceptions such as modifying interupt vectors and bootstrapping). A good compiler can produce highly optomized object code given the right compile commands.

Quote

And with a compiler such as Delphi and VC++, it's easier to add asm statements in code using the asm statements.

Agreed, gcc has a lovely set of extensions for doing this. But its still really bad practice to mix assembler and high-level code (unless you have a good reason for doing so).

Quote

even DX progs use ASM. look at the amazing DX water simulation at gamedev.net. I saw the source(It can be optimized since he use lots of push) but even then it ran on my cyrix at full speed

Id believe that, although I would ask why he used asm code when it runs at full speed on an old cyrix machine. Alternatively have a look at the quake2 source, argueably one of the fastest 3d engines of its time and not a single line of asm in the opengl version (asm is used for the software renderer, but thats unavoidable). You will probably find that most games which do have asm code in them, use it for drivers (as I mentioned earlier) for sound, graphics etc, however with the introduction of libraries and SDKs such as OpenGL and DirectX this is unnecessary.

Im not saying asm isnt fun to code in (Im writting the exec code for MINIX in sparc/x86 asm at the moment) but I wouldnt recommend it as a language for people to learn these days unless they are heading for system programming. Graphics and sound programming is more portable, flexible,  and poses little in the way of a performance hit (modern hardware) with a high-level SDK.

Like I said /everyone/ here is learning, and everybody has their own goals and of way learning. Im merely voicing an opinion, what I do object to is people criticizing and abusing other people directly for their opinions. Were all here to help each other.


Title: Cobra
Post by: relsoft on April 29, 2003, 05:58:19 AM
huh?  As you may already have known, it's not the language but the logic behind the algo itself.  It's not your compiler that is portable its your brain.  
http://www.network54.com/Hide/Forum/message?forumid=13959&messageid=1051547901


"Give an idiot DX, and hell make a dumb DX game, but give someone like Rich Geldrich(or Glenn) QB and he'll make a damn cool game"

look: http://www.rpgdx.net/showcontest.php?contest_id=1


Now, don't preach me about Asm portability in linux, Zsnes and a lot other emulators has been ported with it.  And what lang did Zsknight made Zsnes? C+ ASM. Specifically, NASM.

Look at this codes:

QB:
X=X+1

ASM:
mov ax,x
inc X

Same logic different implementations. Now I'm sure you could convert this to a linux flavored progging lang in no time.

If you look closely, RelGFX's sprite routines uses the same algo as the ASM blit I posted here. Talk about portability. As long as you know the logic behind the algo, nothing would stop you from porting it to your language of choice.

Re: the DX water simulation
  He used ASM because Delphi could only go as fast.  So adding asm would make it fly on a 233 vis-a-vis a pure delphi one which would run but crawl on a 233.


And where did I lambast somebody here?


Title: Cobra
Post by: toonski84 on April 29, 2003, 08:28:06 AM
wait, is this guy saying asm isnt good for coding?  bah.  trust me, buddy, you want asm code.  it's your friend.  and mixing low-level and high-level coding is how you make a large project fast.  i've always seen it that c/c++/decent-basic/pascal make it possible to create complex code that can perform numerous tasks easily, while asm is what you use for individual tasks like blitting.  and no matter how good your compiler is, it's not better than the brain at optimizing, so until that happens asm is the faster choice.

now, as portability goes, unless you're dealing with a mac, the cpu instructions are the exact same, right?  so you'd only have to deal with the os-specific stuff, which is most of it, but in most cases comes in routines so generic they can be switched out.  like routines you create for yourself, makewindow, updateregistry, etc.


Title: Cobra
Post by: LooseCaboose on April 29, 2003, 09:39:42 AM
Sigh.

Quote

Now, don't preach me about Asm portability in linux,


Oh, how come the calling conventions, available interupts and even the syntax differ. Do you recognize the following code, its valid x86 assembley code:
Code:

.data # section declaration

msg:
.ascii "Hello, world!\n" # our dear string
len = . - msg # length of our dear string

.text # section declaration

# we must export the entry point to the ELF linker or
    .global _start # loader. They conventionally recognize _start as their
# entry point. Use ld -e foo to override the default.

_start:

# write our string to stdout

movl $len,%edx # third argument: message length
movl $msg,%ecx # second argument: pointer to message to write
movl $1,%ebx # first argument: file handle (stdout)
movl $4,%eax # system call number (sys_write)
int $0x80 # call kernel

# and exit

movl $0,%ebx # first argument: exit code
movl $1,%eax # system call number (sys_exit)
int $0x80 # call kernel

You will find that if programs using assembler that have been ported to other architectures/operating systems will have different versions of the assembler code for each.

Portability is the art of writting code that can work without modification on any system, the above wont but this will (given a C compiler):
Code:

#include <stdio.h>

int main() {
  printf("Hello World\n");
  return 0;
}

Completely portable, no recoding necessary /ever/.

Quote

And where did I lambast somebody here?

No you didn't, I was talking about Blitz having a short temper with Megaman. Discussion forums are okay for opiniated arguments, but not for absuing people directly.

Quote

He used ASM because Delphi could only go as fast.

Quote

As you may already have known, it's not the language but the logic behind the algo itself.

Very true. It also depends how well you know your language and compiler. For example both of these copy a string source to string dest in C:
Code:

int strcpy(const char *source, char *dest) {
  int i, len;
  len = strlen(source) + 1;
 
  for(i = 0; i < len; i++) {
    dest[i] = source[i];
  }
  return 0;
}  

But the following one is much faster in most implementations:
Code:

int strlen(const char *source, char *dest) {
  while(*source) {
    *dest++ = *source++;
  }
}

Like you said, give an idiot DX and he code a dumb DX game, give a good programmer any language and they will program a damn cool game.

Quote

wait, is this guy saying asm isnt good for coding? bah. trust me, buddy, you want asm code. it's your friend.

Okay, for starters I can code assembler for the following architectures: Mips, sparc (32bit), x86 and the M68HC12. I know when its useful and when its not, and I know its a pain to learn each new architecture, its calling conventions, register sets, etc etc.

Quote

and no matter how good your compiler is, it's not better than the brain at optimizing.

Maybe not, but writting high level C code and then translating to asm would be a much better start than coding asm from scratch. Also, compilers are getting pretty damn smart these days, gcc optomizations flags include such things as: making all functions inline, bulk stack popping, forcing register arithmetic, omitting the frame pointer, loop unrolling, reordering delayed branches, etc etc.

A good read on the pros and cons of using assembley is here:
http://linuxassembly.org/howto/doyouneed.html


Title: Cobra
Post by: Rokkuman on April 29, 2003, 11:16:00 PM
Toonski: A new thread??? I've got a record going here!

Anyhow, as I said before but seemed to get shrouded by other topics, the keyhandler works fine, except that sometimes QB will think I key is being held down that's not. (I tested for the value of certain keys and QB would think they were being held when they weren't) I haven't put any code that forces a key value to go to 1, so can someone give me an idea of what's wrong?

And in other news, Mattress from Mattress Warrior is probably going to be in Cobra. And that's all three QB Characters...


Title: Cobra
Post by: Hexadecimal Disaster on April 30, 2003, 02:23:10 AM
BTW, which keyhandler are you using?


Title: Cobra
Post by: Rokkuman on April 30, 2003, 03:02:41 AM
The one toonski gave me "a few pages back". With kbd%


Title: Cobra
Post by: Hexadecimal Disaster on April 30, 2003, 03:36:03 AM
Hmm... the one that uses INP(96) to read keys.

As far as I remember (AFAIR? Wha...?) you need to clear the keyboard buffer after every check, by using POKE or INKEY$

...that's why I recommended you Milo's code.  :roll:

I'll gonna check it.

-------------------------------------
edited later
-------------------------------------

Yep, it seems that the handler get stuck when using 3 or 4 keys at a time, but the code seems fine. Interestingly enough, the "sticky" keys doesn't always come by using the same sequence, and sometimes the "down-right plus two keys" are read correctly...


Title: Cobra
Post by: relsoft on April 30, 2003, 05:01:43 AM
Pardon my ignorance but if Linux runs on the x86 architecture, x86 assembly would too. :*).  In fact ASM is not a language at all but a syntactic way to issue instructions on a machine level.

If linux do run on the intel x86 architecture so would any flavor of asm that supports it.

BTW, my code is not TASM or MASM or NASM based, it directly index the stack(manualy) registers so porting it would not be an issue. :*)

TASM is different from NASM or MASM as Basica is Different from QB.


Title: Cobra
Post by: na_th_an on April 30, 2003, 06:40:15 AM
Assembly in Linux for i86s is just the same as it is in DOS/Windows. They only differ in the syntax.


Title: Cobra
Post by: ak00ma on April 30, 2003, 08:45:50 AM
ASM is important for every codin' language...everytime something is too slow, you might use ASM to tune it up


Title: Cobra
Post by: Blitz on April 30, 2003, 01:38:51 PM
Are we talkinga bout asm now? neato. Well, i replied to the same thing in the challenge post loose.

Asm is still used allot in the gamedev industry. Becuase there you have lots of innerloops which are time critical. In those situations nothing can replace asm. Not even the best compiler comes near a good asm coder. And it never will, until the day when computers learn to think (and do not twist my words on this one).

However, this does not say that coding something in asm will make it faster then a good compiler. DQB is the perfect example why some people should not use asm and compilers instead.

But compilers ( such as your precious gcc) generate general code. And they can't use such things such as mmx (i'm well aware of vectorC and intel c++), atleast in a good way. For instance, when when coding a sound mixer, you can process up to 24 samples in the same times it takes to process one with normal code.

But ignoring things like that, knowing asm makes you a better high level coder as well. Becuase you know how the computer works and you're able to analyze the code the compiler generates.

That's enough reason to learn it.

And personally, i try to get my code to run as smooth on a p133 as it does on a 3 ghz cpu.


Title: Cobra
Post by: toonski84 on April 30, 2003, 06:23:22 PM
so true.  

nate, the one i gave him came from a raycaster antoni gual made, i think.  it uses a poke to clear the buffer each time, and it fixed, at least with me, the problem with the arrow keys locking up.

i'd still recommend milo's though, because only assembly can properly set interrupt vectors and do it properly.


Title: Cobra
Post by: LooseCaboose on April 30, 2003, 08:30:33 PM
Okay, okay. Im not trying to say that asm is completely useless to learn, just that I would (personally) recommend that people learn high level languages instead. For someone getting into general programming with an interest in making hobbyist games or simple applications, asm is way down the list of programming languages to learn. Moving to the future, things like Java and .NET are pushing programmers even futher away from needing asm. We are probably coming from different angles also, Im mostly into low-level system coding, and you guys are arguing from a game standpoint.

Quote

And they (C compilers) can't use such things such as mmx (i'm well aware of vectorC and intel c++), atleast in a good way

My version of gcc has arch flags for at least the following:  pentium, pentium-pro, pentium-mmx, pentium2, pentium3, k6, k6-2, k6-3, athlon, athlon-tbird, athlon-xp and can compile code that utilises the extended instruction sets provided by each of those architectures. This is difficult for a pure assembley coder because each instruction set is different and multiple asm files would be needed to ensure portability (with a C version you just need a architecture detection script).

Quote

Assembly in Linux for i86s is just the same as it is in DOS/Windows. They only differ in the syntax.

They aren't quite the same when you get into more elaborate asm coding because you have to adhere to the operating systems conventions, such as function call setup, available interupts, alignment rules, etc.

Quote

In fact ASM is not a language at all but a syntactic way to issue instructions on a machine level.

Not quite, most symbolic asm languages contain pseudo-ops and shortcuts. The assembler directives are all pseudo ops, and even some instructions can produce multiple instructions once at machine level. The only example I can think of off hand is one for the sparc where the set operation actually produces a sethi and an or instruction at machine level because a 32-bit word cant fit into a single 32-bit instruction.

Quote

But ignoring things like that, knowing asm makes you a better high level coder as well. Becuase you know how the computer works and you're able to analyze the code the compiler generates.

This is true, but again relates more to someone who is coding at system level, when programming in a highlevel language it is generally a bad thing (IMHO) to be trying to program to the architecture. As I said, most of the asm work I do I work at a high-level language first and then compile to assembler to get a head start. The strcpy code I posted early is an example of knowing what produces better object code in a high-level language.

As for speed of algorithms etc, I disagree completely on using asm. If an algorithm is too slow in a high-level language then it is time to start looking at your data structures and algorithm code to see if you can improve it mathmatically, asm should be a last resort for speed here. (Especially as most modern compilers support optomizations such as loop unrolling and inline functions).

Quote

Asm is still used allot in the gamedev industry. Becuase there you have lots of innerloops which are time critical. In those situations nothing can replace asm.


I havent seen enough comercial game code to be able to comment on this with any amount of certaincy, however I mentioned earlier that the Quake2 source doesnt contain /any/ asm code in the OpenGL version. Not enough game companies are releasing their source code to be able to effectively comment on this. Hobbyist games are not always a good source, because as you said people can code poorly in any language and produce slow code, which may lead them to believe that they need asm code when a little extra work at a high level would do the trick.

So if you are going to learn assembley, then learn when you do and dont need it, how it relates to other languages and what alternatives exist. Dont take what I said to mean that nobody should ever learn asm, I meant that with the vast amount of libraries and advancments in hardware and software speed, asm is becoming less mandatory for general programming. It is still, and always will be highly necessary for niche programming.


Title: Cobra
Post by: relsoft on May 01, 2003, 02:36:33 AM
But then again, why are the most widely used of libs in any language made in ASM?

Portability?

Take any Assembler:

mov ax,yval
Xchg Ah,al
Mov di,AX
shr Di,6
Add di,ax
add di,xval

No modifications needed. :*)

"The is a big difference between something that runs on a 486 as opposed to something that *fly's* on a 486"

And why are you assuming the guy who made the DX water demo using delphi should look at his code again. I've seen the code and it's pretty much Delphi-optimized.  But then he needed asm to make it better. :*) And believe me, the *guy* *knows* how to code.


Title: Cobra
Post by: Blitz on May 01, 2003, 05:51:18 AM
Of course, if you're algo suxs it will suck just as much in asm. The things you're saying are pretty obvious. Look at UGL, a combination of good algos and good asm code. However a compiler could never do that. UGL is as fast at it is becuase good innerloops. A compiler could never even come near those loops.

If asm is so useless why was it used so much before computers had hundreds of megabytes of memory and cpus running at several ghz? These reason was obvious back then, there wasn't even a discussion. They needed to take fulladvantage of every cpu tick. But as cpus got faster and memory larger, they could make large and ineffcient programs. And the reason they do it now is becuase they can.

And gcc isn't even such a good compiler, it's a okay compiler. I highly doubt it uses simd instructions. I'd have to see it to belive it.

And to whoever's using asm code, portability isn't an issue for them. Becuase who actually uses asm? Game developers, for consoles you have to use asm, for pc you're probably coding it for win32. A hobbist, i don't give a horses ass about portability. I don't even like *nix.


Title: Cobra
Post by: LooseCaboose on May 01, 2003, 07:44:49 PM
Quote

But then again, why are the most widely used of libs in any language made in ASM?

Standard C library, possibly the most widely used library of them all is coded in C.  Mesa3D OpenGL implementation is written in C, possibly with some asm code for the device drivers (as I mentioned earlier). Wine, which includes an implementation of most of the win32 api is written in C. The Allegro game library is a mixture of C and asm.

Most game libraries only require the drivers to be written in asm (there is no other way here) but the remaining code can be written in a high-level language.

Quote

If asm is so useless why was it used so much before computers had hundreds of megabytes of memory and cpus running at several ghz?


Can you remember where I said:

Quote

IMHO assembler is hardly worth learning these days unless you plan to do low level system or embedded programming.


Note the phrase "these days", of course it was necessary in days of yore. Modern computers on the other hand a blindingly fast and have plenty of memory to burn. Assembler is still very much required for embedded programming where memory and speed constraints are still an issue. Im talking about application development here.

Quote

And gcc isn't even such a good compiler, it's a okay compiler. I highly doubt it uses simd instructions. I'd have to see it to belive it.

It does support simd instructions. In saying that its a not a good compiler, you are taking the one sided approach of speed again. Yes Intel's C can easily produce faster object code, however gcc runs on a vast number of architectures, has a very good support community (last time I had a problem with it, I got a reply from one of the developers within an hour), a well designed extension set, and excellent integration with other tools (automake, xemacs, cvs, indent, etc). Thats why I use it, not because I want highly optomized object code.

Quote

And to whoever's using asm code, portability isn't an issue for them. Becuase who actually uses asm? Game developers, for consoles you have to use asm, for pc you're probably coding it for win32. A hobbist, i don't give a horses ass about portability. I don't even like *nix.

The same game developers who are now releasing their games (often simultaneously) for win32 PC's, the X-Box, PS/2, Dreamcast etc. Are you claiming that any asm code is portable here? For consoles you code in C just like for everything else, most probably cross-compiled from a PC. As a hobbyist you may not care about portability, but for anybody doing serious development these days its a big issue because there is no single target platform for anything now. Applications are faced with the challenge of running on win32 and *nix and games are faced with a vast array of consoles.

Looking to the future the x86 line may soon be dropped being replaced by the IA-64 architecture, which may have backward compatible IA-32 support , but definitely will not run 16 bit x86 code. Also asm goes completely out the window when you shift to Java or .NET unless you really feel compelled to code directly in byte code ;-)


Title: Cobra
Post by: Rokkuman on May 11, 2003, 07:11:09 PM
Anyways... the only question that comes to my mind is why do the keys get stuck in my game, but they work just fine on that demo... it's the same thing, and it's not like I'm having you hold down 6 keys or anything, the max is 3, and that didn't freeze the demo not once.


Title: Cobra
Post by: Hexadecimal Disaster on May 12, 2003, 04:22:25 AM
I told ya. Use Sedlacek's code and stop worrying.


Title: Re: Cobra
Post by: Rokkuman on May 03, 2009, 01:20:16 AM
Hey.. hey guys.  It works now...

php.uat.edu/~phihaye/downloads/cobra.zip (http://php.uat.edu/~phihaye/downloads/cobra.zip)

come baaaaaaaaaaaaaaaaaaaack