| View previous topic - View next topic |
| Author |
Message |
Bjorn
Demon Hunter
Joined: 29 May 2002
Posts: 1425
Location: Germany
|
 Posted: Wed Dec 03, 2003 1:11 pm Post subject: |
[quote] |
|
Thanks for the support, though indeed the flames where heating up a bit too much. :-) I really do understand the downsides of using wrappers like Allegro or SDL, but indeed have enjoyed the upsides they have.
Nice title screens. I think I like the top and bottom ones more because of their contrast. And then the top one seems suitable for a more modern game.
|
|
| Back to top |
|
 |
darkpagan
Wandering Minstrel
Joined: 01 Jun 2002
Posts: 138
Location: Ireland
|
| Posted: Sat Dec 13, 2003 7:49 pm Post subject: |
[quote] |
|
Nah, I'd go for the middle one, simple but elegant. What sort of RPG is this gonna be anyway? 10+ hours or another miniRPG?
_________________
Smoke me a kipper, I'll be back for breakfast.
|
|
| Back to top |
|
|
Grytpype
Fluffy Bunny of Doom
Joined: 19 Aug 2002
Posts: 18
|
| Posted: Sun Dec 14, 2003 1:27 am Post subject: |
[quote] |
|
(bit late, but what the hey)
Xegnma, those screens are top notch. The stone beam & grass area in the first shot are absolutely faultless, and the sprites are fantastic. I'll never laugh at a 16 colour palette again!
For the title screens, I'd opt for the first or second one. The third seems to be the odd one out to me, with the fluro cartoony writing against the stylish title. I'd say the first one is the standout one IMHO.
Heh, and about the Allegro vs. DirectX thing? Well, there's always a third option - you could be a masochistic dickweed like me & program straight off the hardware!
|
|
| Back to top |
|
|
Xegnma
Monkey-Butler
Joined: 03 Apr 2003
Posts: 53
Location: Trapped in Middle Earth
|
| Posted: Mon Dec 15, 2003 2:12 pm Post subject: |
[quote] |
|
| Grytpype wrote: | | Heh, and about the Allegro vs. DirectX thing? Well, there's always a third option - you could be a masochistic dickweed like me & program straight off the hardware! |
Ain't nothing wrong with that. It's just that they are so many brands of video cards out there. And though they all have a standard VGA card at their core, extended VRAM is usually reserved for high & true color modes, as a result you're limited to 256KB of VRAM on the Standard VGA.
I was going hardcode the videocard myself, and program my game in a VGA hybrid mode, (320x240x16colors) but I really liked how the mock-ups looked at 400x300 resolution. I could program the VGA Card for a 400x300x256 but I end up with limited VRAM to play with. Hence I used DirectX since it has support for my video mode of choice plus access to VRAM.
I was wondering if you guys could help me with an issue.A problem I'm having now is implementing a collision mask using an API like directX. I'm using it for pixel accurate collision detection (I plan on having my sprites move in 8 directions, up/down, left/right and diagonally 45 and 135 degrees). A collision mask would look like a 1-bit image in memory. Each bit in a byte would represent a pixel. And each pixel as a result will have two states, walkable or non-walkable. For every tileset you'll have a maskset(a better way might be to have a masklist and create references to per tile), and a sprite will be tested for a collision with the collision maskset. I could do it using the standard VGA, (thanks to Micheal Abrash's articles) but I have'nt the foggiest how to do it using an API like Direct X, especially considering the different makes of video cards. I've looked at the documentation and I've found stuff on source and destination color keying but that has to do with transparency. Anyone has any insights?
|
|
| Back to top |
|
|
DrunkenCoder
Demon Hunter
Joined: 29 May 2002
Posts: 559
|
| Posted: Mon Dec 15, 2003 3:11 pm Post subject: |
[quote] |
|
Just create the masks in a parallel data structure, so that every image has a mask associated and keep the collision mask in system memory.
Always try to separate your concerns when dealing with drasticly diffrent things.
_________________
If there's life after death there is no death, if there's no death we never live. | ENTP
|
|
| Back to top |
|
|
Grytpype
Fluffy Bunny of Doom
Joined: 19 Aug 2002
Posts: 18
|
| Posted: Mon Dec 15, 2003 3:15 pm Post subject: |
[quote] |
|
Sorry 'bout that, I didn't mean to say that anyone who does code straight off the hardware IS a masochistic dickweed. That came out kinda wrong. I was alluding to me stupidly programming myself into a corner through the decision (long story). I've learnt my lesson though - next time I'll use Allegro or SDL.
_________________
Email survey question: What's the nicest thing anyone's said about you?<br>My reply: Eek! Lookout it's moving!!!
|
|
| Back to top |
|
|
Rainer Deyke
Demon Hunter
Joined: 05 Jun 2002
Posts: 672
|
| Posted: Mon Dec 15, 2003 7:15 pm Post subject: |
[quote] |
|
|
Having used DirectX and SDL as well as having programmed directly to the hardware, I have to say that as long as you stick to standard VGA, programming directly to the hardware is vastly more pleasant than using DirectX. Of course this doesn't apply to SVGA, and SDL beats all.
|
|
| Back to top |
|
|
DrunkenCoder
Demon Hunter
Joined: 29 May 2002
Posts: 559
|
| Posted: Mon Dec 15, 2003 7:54 pm Post subject: |
[quote] |
|
Having programmed for VGA (Mode13 and ModeX) SVGA (VESA and to the metal) under both real and protected mode and having used DirectX SDL and Allegro. I can say that going straight to the card may seem like a nice idea to begin with and can be a pleasant ride for a while it's certianly a dead end as far as compatibility and portability goes.
Concerning DirectX sure it's a bitch to set up and get running but when you actually have the whole shebang running it's quite a nice experience.
Allegro is a nice thing for many people but I didn't like it when it first surfaced for Mode13 and DJGPP and since then the nameing conventions and general lack of structure haven't been getting better.
SDL the little I had the pleasure to use it is really in many ways is a big improvement over Allegro the fact that the programmer behind it was already a profressional gamedev shows (the original author of Allegro has since moved on but the backwards compatibility have been plaquing Allegro since the begining)
Anyhow SDL and Allegro is both great things another intresting alternative is ClanLib that shows quite some promise.
The startup time for using them or even DirectX is really quite minimal to the problems chosing the direct hardware route will ever give you.
_________________
If there's life after death there is no death, if there's no death we never live. | ENTP
|
|
| Back to top |
|
|
Xegnma
Monkey-Butler
Joined: 03 Apr 2003
Posts: 53
Location: Trapped in Middle Earth
|
| Posted: Wed Dec 17, 2003 12:38 pm Post subject: |
[quote] |
|
| DrunkenCoder wrote: | | Just create the masks in a parallel data structure, so that every image has a mask associated and keep the collision mask in system memory. |
I thought about doing that, but all the implementations I've thought of are...errrmm...(god I hate this word)..."SLOW"...
That's why I was trying to find a hardware implementation. In Standard VGA, you sent a byte to a particular register and BAM pixel masking was done through the hardware. In Direct X I have to do that in software since I can't find an appropriate function. Bit-by-bit-checking-IN-SOFTWARE is something to which I can't seem to find a fast implementation ...But then I'm not a very good programmer and my optimization skills suck...Can you give me a bit of psuedo-code to work with?
|
|
| Back to top |
|
|
DrunkenCoder
Demon Hunter
Joined: 29 May 2002
Posts: 559
|
| Posted: Wed Dec 17, 2003 12:49 pm Post subject: |
[quote] |
|
Errr... now Im really befuddled... do you want collision detection or transperency?
My answer intended for checking collisions if you just want to skip pixels while drawing the color keying is your friend under directx.
_________________
If there's life after death there is no death, if there's no death we never live. | ENTP
|
|
| Back to top |
|
|
janus
Mage
Joined: 29 Jun 2002
Posts: 464
Location: Issaquah, WA
|
| Posted: Wed Dec 17, 2003 1:00 pm Post subject: |
[quote] |
|
|
You can't do collision detection in hardware... why would you want to?
|
|
| Back to top |
|
|
DrunkenCoder
Demon Hunter
Joined: 29 May 2002
Posts: 559
|
| Posted: Wed Dec 17, 2003 1:14 pm Post subject: |
[quote] |
|
| Janus wrote: | | You can't do collision detection in hardware... why would you want to? |
I simply can't get what he's actually trying todo first I thought it was collision detection but the later post he starts talking about standard VGA and all of the sudden it sounds like colorkeying.
I think we all need a better explanation before we can get close to solving this problem. Both problems are quite simple to solve but right now the true question just evades us.
_________________
If there's life after death there is no death, if there's no death we never live. | ENTP
|
|
| Back to top |
|
|
Xegnma
Monkey-Butler
Joined: 03 Apr 2003
Posts: 53
Location: Trapped in Middle Earth
|
| Posted: Fri Dec 19, 2003 3:58 pm Post subject: |
[quote] |
|
| DrunkenCoder wrote: | I simply can't get what he's actually trying todo first I thought it was collision detection but the later post he starts talking about standard VGA and all of the sudden it sounds like colorkeying.
I think we all need a better explanation before we can get close to solving this problem. Both problems are quite simple to solve but right now the true question just evades us. |
Sorry for the confusion. Okay let me try and clear this up. My goal is to implement collision detection using what I call a collision mask. I only refered to color keying because it was the closest analogy I could find in DirectX to what I wanted to do. Now in reference to Standard VGA programming, there is a way you can implement masking via the hardware (8-pixels at a time), by setting a particular write mode, and sending a byte to the Bitmask register( if I remember correctly). That byte is used by the register to decide which pixels get written to the screen and which do not - essentially a mask. Now this has nothing to do with collision detection either, except I thought maybe it could be used for that purpose, which after thinking about it probably isn't possible. My mind tends to wander when trying to figure stuff out. I think that was were I messed up in trying to present my goal. So let me revise it, I am looking for an extremely fast way to implement collision detection using a 1-bit image to represent a tile's mask data (the 1-bit image is more natural to work with).
Heh, all of a sudden I'm reminded of my Comp & Lit II professor :"Always make the thesis of your paper clear and precise, vagueness always limits a paper's effectiveness".
Last edited by Xegnma on Fri Dec 19, 2003 4:16 pm; edited 1 time in total
|
|
| Back to top |
|
|
Xegnma
Monkey-Butler
Joined: 03 Apr 2003
Posts: 53
Location: Trapped in Middle Earth
|
| Posted: Fri Dec 19, 2003 4:04 pm Post subject: |
[quote] |
|
|
Whoa, I think I may have found a solution, It kinda came to me after I submitted the last post. All your comments helped though, in that it kinda forced me to focus more on the problem.
|
|
| Back to top |
|
|
DrunkenCoder
Demon Hunter
Joined: 29 May 2002
Posts: 559
|
| Posted: Fri Dec 19, 2003 7:45 pm Post subject: |
[quote] |
|
Let me guess, it involves bit-masks and logical operations...
_________________
If there's life after death there is no death, if there's no death we never live. | ENTP
|
|
| Back to top |
|
|
