Assembler, graphics & sound

** I realise that I am probably alone in any attempts to game program in assembler. I realise I should use C++ **

Never the less !

I am used to C64 (If you remember them) and Amiga type architecture...which is to say the graphics/sound chips are standard and if you want do stuff you manipulate certain absolute addresses (and the stuff happens).

These newfangled "Frankensteinian" PCs have a range of graphics cards, sound cards (to go with a range of CPU's). So I imagine that if I am to write a game I need to either : use interfaces that support the popular cards or write several versions of my game (after aquiring the specs for all these cards and sussing them out). Any good advice (apart from the obvious which I covered in my opening) ?


Comments

  • Sure, hints:


    1. write the game in protected mode (since you are from the c64/amiga background you probably won't do windows assembler, right? :-P)

    2. doing all kinda grafix cards in assembler is not that much hard work... (only a year orso to get a single screenmode working on most cards *huge grin*).

    3. doing all kinda soundcards really is sucky business, if you want your game to sound right. ofcourse you could opt for adlib music and simple sb-compatible soundfx, but that would be lame. and still kinda hard, because here on pc we have to mix our own soundbuffers on most cards *shriek*.


    Believe me, it is pretty darn close to impossible. Especially the sound support. For example, a fairly good, pretty compatible soundengine in C/C++ mixed with assembler tops at about 30.000 lines of code.. for pure assembler that number probably mulitplies by 3... you just go ahead and try doing that *urg*... you might ofcourse opt for NO compatability, or just basic sounds, which would be a lot easier.


    Good luck! If you make it I'll give you a HUGE round of applause!


  • : ** I realise that I am probably alone in any attempts to game program in assembler. I realise I should use C++ **

    : Never the less !

    : I am used to C64 (If you remember them) and Amiga type architecture...which is to say the graphics/sound chips are standard and if you want do stuff you manipulate certain absolute addresses (and the stuff happens).

    : These newfangled "Frankensteinian" PCs have a range of graphics cards, sound cards (to go with a range of CPU's). So I imagine that if I am to write a game I need to either : use interfaces that support the popular cards or write several versions of my game (after aquiring the specs for all these cards and sussing them out). Any good advice (apart from the obvious which I covered in my opening) ?


    I believe you may have a few misconceptions.


    First of all, Assembly is really only useful if you're planning on making FAST executing graphics. It may be useful if you're trying something that needs to modify the screen, say at in excess of twenty times per second. Nowadays nobody really depends on assembly for the fact that computers are so much faster than before. We can afford to be a little more inefficient. However I wish Microsoft (more like Macrosoft) would not adhere to the previous statement.


    Also for the most part, it is WORSE to program in assembly than in C/C++. If you're programming in assembly you're programming for ONE platform and ONE platform alone. This can also include the sound/video card you're programming for. With C/C++ you are, for the most part, writing a script language that can be compiled for different platforms. Now with DirectX and such, programmers simply need to call the graphcis and the OS will send the correct signals no matter what the card is.


    You're used to Amigas which were built the same with the same specifications for assembly. Assembly was useful in those days because it was CONSISTENT and you didn't have to change your code to fit someone's odd card. With PCs, or any other computer system for that matter this is not the case. However for the most part, the only card-specific programming you'd have to do is for special 3D effects cards. All other cards basically have the same functions.


    -Xotor-


  • Thank you both for your sound advice. Err....and your graphics advice as well. You have made me falter...perhaps an assembler game that execs C/C++ routines for graphics, sound ? That would be putting the horse before the cart I know but it's something I'll think about. Come to think of it there's not too much more to games. Damn.

    OK I have some other questions then - are the makers of DirectX (for example)going to horn in on my racket if I revolutionise computer gaming as we know it *harhar* if I do so using their product (ie. will they want royalties)? If C/C++ has funky sound/graphics commands, why when I pick up a C/C++ manual do I only ever see hundreds of pages devoted to data handling, string manipulation and none devoted to graphics, sound functions ?

    I'm sure if I make a journey into assembler it will be useful for something, oneday. Anyone got any memory maps ? (Serious question).




  • : Thank you both for your sound advice. Err....and your graphics advice as well. You have made me falter...perhaps an assembler game that execs C/C++ routines for graphics, sound ? That would be putting the horse before the cart I know but it's something I'll think about. Come to think of it there's not too much more to games. Damn.

    : OK I have some other questions then - are the makers of DirectX (for example)going to horn in on my racket if I revolutionise computer gaming as we know it *harhar* if I do so using their product (ie. will they want royalties)? If C/C++ has funky sound/graphics commands, why when I pick up a C/C++ manual do I only ever see hundreds of pages devoted to data handling, string manipulation and none devoted to graphics, sound functions ?

    : I'm sure if I make a journey into assembler it will be useful for something, oneday. Anyone got any memory maps ? (Serious question).


    I don't thing the makers of DirectX (Microsoft that is)will want any royalties...it's like saying they would want royalties for you using Interrupt 21h of DOS... but again...not sure...Microsoft is a strange world :-)

    BTW... In my opinion DirectX is one of the few good thing MS has made.


    you said something about the manuals not talking about grafix.

    Ussualy the standard C libraries come with simple graphics routines, which are ussually slow, not good for games. There are libraries dedicated for making games, and in this, you will not find any data handling instructions (that is , if you don't consider a bitmap file, some kind of data :-) )


    and for the memory map, you can download helppc at http://www.fys.ruu.nl/~faber/Ahelppc.html

    which contains a memory map, an interrupt reference, and an assembly and C mnemonic table...


    good luck with your asm game (I started one, but I stoped now :-) I thing I am turning in C, but using many of my own functions made in asm)


    /Andreas




  • Why do people feel that we (as programmers) have some kind of

    responsability to support some f***ed up port configuration that a

    company arbitrarily dreamed up? It's because people have bowed to

    the hardware people that things are in the sorry shape they are.

    SUPPORT THE HARDWARE STANDARDS ONLY, SCREW THE REST! This goes for

    Matrox, who has stated they're not bothering to make their cards VESA

    compatable because it's "obsolete", the Windows Sound System (If anyone

    bought one in the first place) and arcane 3D cards.

    If you want to add features to your program, do it via a hardware

    standard, for example:


    Sound Blaster 100% compatable

    VBE 3.0 or below

    VBE/AF 2.0

    PCX2 Standard


    Most of us are people whose livelyhoods don't depend on bowing to

    every suckers whim. If we just start making products that use the

    standards, the hardware makers will feel the pressure to make products

    that obey them. We can make programming a much more developer-friendly

    place.


    Ok, that's my rant. Thanks for reading.


    Matthew Gross


    URL:http://acheronx.resnet.tamu.edu

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories