I'm building a fighting game and you would need to have the charecter move all over the place. I've gotten basic sprites that I created from DATA statements and saved into memory and than had them redrawn using the PUT command. Without using any libaries what is the best way to make your sprite move. The sprite would be .gif probably and constantly animated. Is their a way to create layers, if so can someone point out how. I believe it had something to do with SRN 7. Speaking of Screans is their a way to create your own screen mode without libaries. I need all the colors of SCRN 13, the size of screen 12, and the layers of screen 7, and the ability to create trasparent text from screen 0.
Once again the majority of this discussion is what's the best techqnique for moving sprites in a fighting game.
Well man, you need a library if you don't want to study 2,000 tutorials on every aspect you need.
1. To get the video modes you describe, you need to know VESA and code it in low level, which can be a very hard task, which needs a lot of work.
2. In such a video mode, you'd need custom PUT and GETs, and also some double buffering technique that you'll have to code yourself. If you don't do this in assembly, your program will crawl.
If you are asking for code, then you are asking for a library. Maybe you mean "PureQB". If so, then no SVGA library in pure QB exists that is usable and fast enough to make a game (at least you have a 4 GHz PC).
I consider that when you are moving to SVGA modes you better use a library. It is not that easy as it happened with Mode 13h. You'll have to deal with banks, offsets and difficult stuff.
If you are a graphics code, then go ahead. If you are a games programmer, I'd suggest you to focus on game programming, and leave the GFX stuff to experts.
I strongly recommend you that you get UGL right now. And don't say that it is hard to work with 'cause it isn't. And if it would, it would keep being easier than coding all that stuff yourself.
___
As for the main part of this discussion... Well, I'd suggest using the console/arcade technique in which your sprites are subdivided in smaller tiles (16x16 commonly). You need some kind of application to map the smaller tiles and build your characters on screen like a lego.
With this technique you get faster results as you'll draw less pixels (imagine a big rectangle with lots of transparent, unuseful pixels to skip). Furthermore, this technique provides a easy way of checking where the characters got hit, just looking which tiles collided.
So their absolutly is no way to do it with out a libary or low level programming. This absolutly sucks. The computers I stuck working on are the ones in school and while I may be able to get the program to work at home. It wont run in class. Well i'll see what I can do.
I'd like to change the discussion focus than. Now USING a libary. Which libary do you recomand, and how would you do it. I would also like to say that I want some flexibility to be able to improve things whenever possible. Not that I will, but I might.
PS: What's UGL
UGL is a very fast and IMO userfriendly game library. It includes SVGA,Keyboard,Mouse,......
I think at the moment it's the best one
i'd (like most fighting games) keep the sprites stored in 8x8 blocks and put together with simple maps, and use this maps for simplified but mostly accurate collision detection. the maps should be as wide as wide as the sprite'll ever get and tall as the sprite'll ever get. then keep and x and y for over all position and move that around depending on keypresses. that's mostly the easy part.
toonski where can I find a tutorial on maps, or can you provide me with a quick sum up of steps needed to create them and how they work.
Concerning the libary issue check out wizardlife's post
here
This is what I wanted to do from the start but didn't want to make a dumb assumtion that you could.