Qbasicnews.com

Full Version: Cobra
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
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.
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.
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.
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/mess...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?
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.
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
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...
BTW, which keyhandler are you using?
The one toonski gave me "a few pages back". With kbd%
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...
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19