NetNews Usenet Archive 1992 #31

home *** CD-ROM | disk | FTP | other *** search

/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / ibm / pc / soundcar / 5770 < prev next >

Wrap

Internet Message Format | 1992-12-26 | 14.8 KB

Path: sparky!uunet!munnari.oz.au!nutmeg!nunn Newsgroups: comp.sys.ibm.pc.soundcard Subject: THE README FILE (FRING11.lZH) Message-ID: <1992Dec23.112503.4453@darwin.ntu.edu.au> From: nunn@it.ntu.edu.au (JsNO BAR---NUNN) Date: 23 Dec 92 11:25:01 +0900 Reply-To: nunn@it.ntu.edu.au References: <1992Dec23.112043.4452@darwin.ntu.edu.au> Distribution: world Organization: Information Technology, Northern Territory University Nntp-Posting-Host: nutmeg.ntu.edu.au Lines: 449 READ.ME FILE FRINDGUS (An incomplete game) (14/11/92) ---------------------------------------- By Jason Nunn (JsNO BAR----NUNN) nunn@pandanus.cs.ntu.edu.au (Note: This is a quick "slap-up" documentation, I'll do a better job later.....but for now) A VGA GAME ---------- Hello, I started this game "FringDus" a couple of months ago. Due to the fact that I've completed my degree (hence unemployed), I have to find a job. I'm also nackered after my computing project which clocked up 25000 lines of Pascal code in 10 weeks and MONTANUS is still isn't finished!. Basically I'm getting too old for this sort of stuff, and now giving it to someone else; the idea's and concepts to write a game. Another reason why I'm "throwing it in", is because I have absolutely NO artistic talent what's so ever!. When it comes to programming, I'm good, but when it comes to designing graphics- I'm absolutely shithouse. All code is totally freeware. YOU CAN DIRECTLY USE THIS CODE IN GAMES ETC. LEGALS ------ - I do not take any responibility of any hardware/software loss or any other loss that is the direct/indirect consequence of seeing/using this code/executables. (To my knowledge, this code is completely safe. The only reason I'm giving this warning it because everybody else does!.) - You may freely use is code. You may use it directly in your source, even if you make Millions of Dollars on a game you made using this code. It only took me a night to write the basic code so it's no skin off my nose (I took me alot longer to design the graphics though!). DISTRIBUTION ------------ This distribution comes with: fringdus.pas <game source> pic_make.pas <sprite maker source> map_mak2.pas <map maker source for editing the FRING1.MAP file> pack.pas <transforms *.PIC (sprite graphics) to the FRINGPC1.PIC file> fringdus.exe <the excutables> pic_make.exe mak_mak2.exe pack.exe pack.ini <the pic list that pack reads to dtermine which pic files to append to "fringpc1.pic"> flr1.pic thru to- flr32.pic <the individual sprites> b_scr.bmp <The base screen file (in windows format)> bs.bat <Boot scrap compiling sequence, with the relevent flags etc> Very Techical Notes & Discussion Notes -------------------------------------- FRINGDUS.PAS: ------------- Have you ever heard of Paradroid?. It was a game I used to play on a friends C-64 a long time ago (1987). I reckon it was the best game ever written. Fringdus has the same scrolling effect of the graphics as Paradroid. It looks really good!, I'm really impressed with what I have done. As you operate the key-pad keys, it looks like the "ground floor" is moving under you. It looks very smooth, but still needs some modifications so that it is faster. The computing solutions are the first solvable solutions, not the best ones. Basically, the code that resides in the Pascal source: "FringDus.pas" is like a Database Manager. It manages a 2 entity 1-N relational database. The ERD (Entity Relationship Diagram) is below: ^ ---------------- / \ --------------- | | 1 / \ N | | | FRINGPC1.PIC |------/ HAS \----->| FRING1.MAP | | | \ / | | ---------------- \ / --------------- \ / . It copies blocks of graphics contained of the "FRINGPC1.PAS" (FRINGdus PiCture 1) file (which is stored in memory), according to what the "FRING1.MAP" tells it (also stored in memory). The "FRING1.MAP" file is really the "map of the floor", which only contains position references to the blocks of graphics in the "FRINGPC1.PAS" file. (Note/ From now on, we'll call the blocks of graphics: "Sprites"- from my good old C-64 days :) ). When "Fringdus.exe" is executed, the computer reads a section of the "FRING1.MAP", It reads the relative locations of the sprites in the "fringpc1.pic file. It then reads the sprite and then copies it the video memory located at decimal address 40960 (A000h). The screen dimensions for Fringdus are: 320*200 pixels (or 64K of memory). (Note that this for VGA only. You will have to make the relevent changes to the code to turn it in to a EGA or CGA game.) Fringdus provides a quick assembly base to copy chucks of data to the video (invisible) memory. As you will see, many of these assembly routines are tailor made for certain situtions. The problem is with graphic libraries is that they are standardised. The problem with standardised anythings, is that they compensate for any kind of situation (philosophically speaking). Hence they are slow. If you want speed, you need to custom make routines for only certain situtions in assembly. Disassembled 3GL's like Pascal are very Stack intensive. There is alot of overhead in preparing values for the registers. Analagously, they "have a few drinks, watch a few porn's, have a couple of games of pool, then go to sleep" before they do they they useful. With assembly, you can "contain" the processing, within the action registers AX, DX, CX, BX, so that processing is very fast. These routines are in no way efficient. I don't consider myself an assembly expert. An assembly expert will look at these routines and speed them up by 5 times, because they know what intructions are fast and what instructions are slow. A lot can be said about Assembly experts, but we won't go in to that now. NB/ A detailed look at how they work, is in the source documentation. If your still having problems with how they work, write me. I haven't documented them properly, but will. Remember!, I might be documenting for a living, so please remember that cooks don't like cooking when they get home :). The sprites are 30 pixels by 30 pixels, as follows: (NOT TO SCALE) 30 X ------------------------------- | o o o | 3 | o o o o o o | 0 | o o o | | o o o | X | oooooooooooooooooooooooooo | | o o o | | o o o | | o o o | | o o o o o o | | o o o o o o | | o o o o o o | ------------------------------- Each pixel (due to being VGA) consists of 1 byte to define it. As said before, these will get copied to the memory block: 40,960-106,495 (320*200 256 colour). These sprites are 900 bytes in length. I don't know why I chose 30x30. It looked a pretty optimal matrix. As you move smaller blocks, you get a high CPU load but the less blocks you have to store, the more diversifable grpahics you have because you can make more graphics with smaller blocks. As you move bigger blocks, copying becomes more efficient, BUT you need alot of memory to have a diversifed array of graphics. Fringdus reads the fring1.map (now in memmory), to determine what sprites to copy. It looks simliar to this: (AGAIN, NOT TO SCALE) 100 X -------------------------------------- | shhhhu | 1 | d d aaaaau | 0 | d d d | 0 | d d d | | d d d | X | hffffl d | | d | | d | | d | | d | -------------------------------------- It is a 100x100 bytes. Each byte presents a sprite. As you may be wondering, this is a huge area. In real terms it is 3000*3000 pixels. Again, each byte contains a reference to a given sprite in the "fringpc1.pic" file. For example, if the value of a given position in the above map was say "4" (the 5th sprite), then the position of the fifth sprite would be at offset 4 * 900 = 3600...simple. It would go to postion 3600, copy 900 bytes from that offset, and then paste it to the screen (in a simple sense). 35 sprites are copied on the screen to define the floor surface, starting at coorinates (50,30). It look as follows: (NOT TO SCALE) ----------------------- | /- starts at 50,30| | | | | x x x x x x x x | | | | x x x x x x x x | | | | x x x x x x x x | | | | x x x x x x x x | | | | x x x x x x x x | | ^ sprites | ----------------------- If the sprites are not at their discrete postions, they will be scrolled. The assembly algo's, cut the border sprites so that they don't leak out from the painting area (this unfortunatly, takes up alot of O/H). The key-pad keys, change the value of a marginal dx & dy values that change the value of the real x & y values. These values determine what sprites to copy when compared with the map file (fring1.map). For example, if real x and real y were 244 and 345 respectively then fringdus will refer to the map file at postions: x: (244 / 30) thruto (244 / 30) + 7 y: (345 / 30) thruto (345 / 30) + 5 When "mod"'ed (eg X mod 30, Y mod 30), they determine the degree of scroll from the offset discrete position of a given sprite. The operation keys are as follows: home pgup \ | / - - (key pad) / | \ end pgdn PIC_MAKE.PAS: ------------- I had to make my own sprite graphics program to make the sprites. The code is obvious, therefore I'm only going to briefly explain it here. This program makes a 30x30 256 colour sprite that PACK.EXE will pack into "fringpc1.pic". To execute this utility type in: Command: PIC_MAKE <sprite file> NB/ You don't have to have the PIC extension, it can be anything you like.) The operation keys are: | - - (key pad) | Enter Key: To write a pixel in the sprite the selected colour. -: GO up one colour +: Go down one colour /: Go up 10 colours *: Go down 10 colours. `: Fload full sprite with colour Esc: Exit (Abend) s: save present sprite f: flip sprite and save (flips vertically) t: turn sprite and save (flips horzontally) Once you have composed something, then you ever hit 's' for save or 'f' or 't' to save. Once saved, then you hit 'Esc' to exit. The reason for the 'f' and 't', is that it saves you alot of work recomposing a drawing that that only needs to be "turned around" etc. If you want a mirror image of something, just create a clone copy of the sprite you want to flip or turn (eg IN DOS: copy jas1.pic jas2.pic), then load it up (eg pic_make jas2.pic). Once loaded, you can turn or flip it with the appropriate 'f' or 't' key. Once done- hit 'esc'. PACK.PAS: --------- Creates the "fringpc1.pic" file whichs contains the sprites that Fringdus reads. Pack read a list of pic files (*.pic - doesn't have to have the PIC extension, it can be anything) and then appends them to "fringpc1.pic". command: PACK Once executed, pack reads the 'PACK.INI' file, and moves/appends the files that are in this directive file, to the 'fringpc1.pic'. MAP_MAK2.PAS: ------------- This program edits the map file: "fring1.map". There was a map_make.pas, but that was an initiating program that was really shity. This program allows you to change the sprite references- hence the sprites to be displayed. To execute, type in: Command: map_mak2 The Operation keys are: | - - (key pad) | :This is a block scroll i j k :Once positioned with keypad, you move around with these keys m enter: When you want to change a value in the map file matrix simply hit this key. You then enter in the new value. If you were repeating the same value (the same value last entry), then just hit enter without entering in the value again- this makes entring data alot faster (and less frustrating). s: 's' saves fring1.map. Once saved, it immediately exits. bs.bat: ------- Boot strap compiler sequence. With tpc (Borland Turbo Pascal V6) in your path just type in: bs. Fringdus will be built with the relavent compiler flags. b_scr.bmp: ---------- The base screen. Fringdus writes this file in video memory initially. You can edit it this file to your needs using windows "paint Brush" for example. (Note, I don't know the BMP format, I've just took a rough stab, just by displaying BMP's raw, and determining the format. Please send me the correct BMP format) *.pic: ------ The Individual sprite files before being packed. Enjoy :). Feel free to contact me if you don't understand something, or can't that something working. ooo0ooo ----------------------------------------------------------------------------- JsNO BAR----NUNN Spelling Disclaimer: "MY SUN keyboard is a chunk of shit" "Computer Science students learn how to become computing professionals, Business Information Systems students are users learning about themselves" NTU, DARWIN, OZ nunn@pandanus.cs.ntu.edu.au ----------------------------------------------------------------------------- or snail: 8 Winton Street, Jingili, Darwin, NORTHERN TERRITORY, 0810, AUSTRALIA.