| |
Verge needs... Displaying 1-20 of 27 total.
12
next
resident
|
a controller update. Specifically, full support for the Xbox 360 controller and all it's associated widgets.
As far as I'm concerned, the 360 controller is "the official PC games controller (for any game that isn't a first person shooter)", and it seems to me like support would basically require an extension of the standard d-pad and 4 button joypad. (I tend to think of Verge as a virtual console).
I mean, it already *works*, but having access to both sticks, the d-pad and all 10 buttons in Verge would be AWESOME.
Posted on 2005-12-07 07:31:00 (last edited on 2005-12-07 07:31:48)
|
Omni
|
You do, don't you? Support for up to 31 buttons?
However, I wish that Verge did support more than one joystick axis. Maybe an array like
int joy.analog[axis]
With up to four axis supported, or somesuch.
But I wonder? We have "joy.left" and right, and down and up and so on. But are those also wrappers for the X and Y joystick, or are they for the POV hat?
Posted on 2005-12-07 09:02:45
|
blues_zodiakos
|
And here I thought the mouse was the official PC games controller. I'm not even sure I know anyone besides myself that even has anything resembling a joystick - and mine is just a PS2 to USB adapter so I can play stepmania with PS2 dance pads.
I see what you mean though, more support is always good. Problem is, Microsoft is forcing people to use the new Xbox-360 controller extention for DirectX for people to use it, and verge3 doesn't use DirectX.
Posted on 2005-12-07 09:45:04
|
mcgrue
|
http://www.verge-rpg.com/files/detail.php?id=408
Posted on 2005-12-07 09:54:54
|
resident
|
Awesome.
Didn't know Verge supported button numbers that high! For some reason I thought we just had 0-3. Possibly because I'm a drooling moron.
FYI, you don't seem to have to use Direct X at all. Mine maps as a normal joypad in XP and works just fine in Verge (though the stick is a little bit shaky for digital input - shame I can't use the D-pad which is mapped as a hat switch).
Possibly the reason it works the way it does is because I just plugged a standard 360 wired pad (not the 360 pad for Windows XP - just a standard 360 pad) straight into the USB port and let it pull drivers for it off WindowsUpdate.
You're also right about the keyboard/mouse being the standard PC controller. This is why console style games usually suck big time on the PC. In the past, many ports have had support for the Microsoft Sidewinder pads, though, so it seems reasonable to assume that they'll have similar support for the 360 pad.
A 360 pad may well become all but obligatory for PC games that aren't first person shooters, and in some ways, I hope it does since it could sidestep all the tedious control configuration you have to do in many games.
Posted on 2005-12-07 11:17:39 (last edited on 2005-12-07 11:23:03)
|
blues_zodiakos
|
I totally and completely stand corrected though... I just got the source, and Verge3 does indeed use directX, at least for the rendering. I haven't looked far enough to see what all else it uses.
-edit: I should clarify my original post too... I didn't mean that you have to have DirectX to use the controller, but that the developer has to compile with DirectX in order to use all the buttons and features in their program, I assume for now... this may have changed though.
Posted on 2005-12-13 01:53:45 (last edited on 2005-12-13 01:57:48)
|
Overkill
|
Verge3 uses DirectX for inputs, I'm fairly certain. After all, explain why the DirectX key scancodes direcly relate to SCAN_* constants and why if I google for some of the key indices that aren't defined (Like the actual Insert, Delete, Home, End, Page Up and Page Down keys outside of the numpad), it will work.
Posted on 2005-12-14 15:05:45
|
blues_zodiakos
|
You are right about that, because it took me a bit to figure out why DINPUT.h wasn't linking correctly into the solution (turns out the DirectX SDK installer doesn't add itself automatically to Visual Studio 2005's library and include search directorys, doh). The 360 controller support is actually part of a new seperate DirectX API called something I don't remember, but it's silly that they made it that way instead of smooshing it into directinput.
Posted on 2005-12-14 15:57:16
|
yhnmzwcs
|
I want extra verge.cfg controls for the window: aside from 'windowed', 'automax', and 'resolution', I want a setting for window scaling (320x240 may be for winners, but it's vanishingly small on my monitor.) That is, if I set:
xres 320
yres 240
...
windowscale 2
I get a 640 by 480 window, but 320 x 240 in the programming.
Alternately, you could make the screen catch better at the right sizes, like it does a little bit. Make that less sensitive and I'd be happy.
Posted on 2005-12-15 16:59:30
|
Omni
|
You can easily program in your own windowscale feature.
Just set your resolution to 2x of what you want. (IE, game runs in 320x240. So use 640x480).
Then program your game as usual, BUT! Don't use ImageWidth(screen) or Height. Have some defines, like SCREEN_W 320, etc.
Then, make a custom ShowPage().
void my_ShowPage()
{
ScaleBlit(0, 0, ImageWidth(screen)*2, ImageHeight(screen)*2, screen, screen);
}
That SHOULD blit the screen at doublesize to itself. ...maybe. (thus doubling the 320x240 to 640x480). Assuming you always only draw to the 320x240 region, you'll get a double-scaled screen.
If blitting screen directly to screen doesn't work (possible), then do a quick Imageshell [edit: this actually involves nothing like ImageShell]. Like so.
int myshowpage_temp = NewImage(320, 240);
void my_showpage()
{
blit(0, 0, screen, myshowpage_temp);
ScaleBlit(0, 0, 640, 480, myshowpage_temp, screen);
}
There. Search and replace for your ShowPage functions. Search and replace for ImageWidth/Height to your constant SCREEN_*.
Not perfect, but in principle very simple, and decently fast. My screen horizontal interpolation that I posted for Zip's Code Vault thread in Verge Help (do a forum search if interested) does the same thing...but with...er...horizontal interpolation.
Posted on 2005-12-18 12:21:38 (last edited on 2005-12-18 12:23:16)
|
resident
|
Plus that version has the advantage of, say, allowing you to scale up the screen, THEN draw stuff like textboxes at the full screen resolution with a higher resolution font which would look much nicer.
Still, a scaling routine written into VERGE with emulator style filters would presumably be a bit faster, as well as look nicer. While I'm sure it's possible to do it internally, you're bound to take a bigger performance hit.
Posted on 2005-12-18 14:41:57
|
Omni
|
Hey. We improvise or [now] we patch the source. I'm not a competent enough C programming to add it myself, so I'll be happy with what I've got.
In addition, you can fake your own emulator filters.
Make your own wrapper for the image functions that pre-applies the filtering for you. That gives you the benefit of filtered graphics with absolutely no speed hit (at higher RAM usage, but hey, so does your PSX-emulator with special texture filters).
EDIT: Technically this wouldn't work with maps since you have no control over the loading of the VSP graphics data. So make your own map system :)
Posted on 2005-12-18 15:37:51 (last edited on 2005-12-18 15:38:37)
|
resident
|
I agree. I really like the idea of blown up 320x240 sprites with higher resolution fonts.
Posted on 2005-12-19 02:07:55
|
mcgrue
|
Actually, this all-in-vc mod that Omni suggested I had in place in my local build of SotS over a year ago... although I wasn't doing it for higher-res fonts (although the idea crossed my mind) but for having the original art usable while having higher-res manga cels so Ira's art wouldn't be wasted on 320x240.
Ira's the original cel artist from the earliesrt SotS demos, for those of you that remember, and he's recently been published in a few commercial indie collections of comics. His website is the one that's been in my signature for the past year or so (I built his site for him).
Again, for those interested, the style of art I'm going for in SotS is best demonstrated in his Good/Bad intentions shorts, viewable here and here.
For anyone interested in the upscaling mod, I did it in the Sully base library, and will provide it in the near future (if there's a desire).
Posted on 2005-12-19 05:51:11
|
Omni
|
I had actually planned to use the Scale2X code for a similar image library. McGrue, what kind of upscaling do you do? And...it doesn't work on the maps, by any chance, does it?
And I really can't make sense of 2xSAI code. It seems very complicated. But assuming you could make sense of it, you could make your own filtered image support library with it.
Posted on 2005-12-19 09:34:24
|
mcgrue
|
Of course it works on maps. That was the whole point, to scale up everything except very specific things.
...It's sinfully simple. It's just a screengrab of everything rendered to the screen, a blowup, and a blit back to the screen, all HookRendered.
This is not an engine mod. It's just vc.
Posted on 2005-12-19 12:42:49
|
Omni
|
Aha. Excellent.
Posted on 2005-12-19 15:50:52
|
resident
|
I'd be interested to see how you've done that. I've sort of got it to work.
Basically, I've taken the orginal 640x480 screen, and grabbed the 320x240 portion surrounding the player entity, then scaleblitted it back to the screen but there's graphical glitching around the fringes of the map, most probably due to my suspect maths ;)
I'll spend a little time tweaking it and checking the math later (or I could just sidestep the issue with a buffer zone around the edge of the map.
Posted on 2005-12-20 05:16:58
|
Omni
|
Resident, the problem with the glitches on your scaling is that you're grabbing the 320x240 portion around the player.
So when the player is at position 0, 0 on the map, then the position 0, 0, is in the middle of your screen grab.
So what's to the left? And the top? Nothing. You're grabbing outside of video memory.
To fix this, you essentially need to add camera detection to your screen grabber. I can't quite think of the conditionals, but just something to make sure that the rectangle you grab never goes outside of X, Y 0, 0.
Posted on 2005-12-20 15:08:03
|
resident
|
Which is why I'm curious as to how Grue got around that ;)
The effect is interesting. It's like that happens in Doom when you use the noclipping cheat and wander out of the area of the map, with the "outside" of the map being composed of the areas that used to be there.
Interesting that grabregion will allow you to grab "off the map" though.
In theory it should be safe enough to do that I'm doing, though. The only time I'm referencing memory outside the bitmap is when I'm grabbing data, so I could probably get away with the buffer zone.
Posted on 2005-12-20 18:51:17 (last edited on 2005-12-20 18:57:06)
|
Displaying 1-20 of 27 total.
12
next
|
|
