Messages

[Welcome to the forums!]

Welcome to the forums! We're glad to have you here! :) You can register your account here, then feel free to introduce yourself in the Server.Warcraft2.online board & let us know who you are on the server.

1576

Support Requests / Re: Force change resolution

« on: November 17, 2016, 11:12:22 AM »

Damn!

Okay so their is a referenced string for display adapter you can find with cheat engine, etc. Change that also!

Also another tip! Try to hex ddraw.dll!

Actually, now I look at it, bne is just using standard windows gdi stuff. The DOS version would use interrupt 16 and mode 257. But wc2.exe and storm.dll only import graphics stuff from GDI32.dll and USER32.dll, so its all just device contexts...

ddraw.dll (directX) isn't imported by anything, in the traditional way. It's being dynamically loaded by one of the sneaky little embedded code modules blizz use. It seems they only use:

CreateBackSurface
SetPalette
CreatePrimarySurface
SetDisplayMode
DirectDrawCreate

Which is just a very basic set of initialization routines. Also there's a help message in there for the event where it can't use directX, telling you to set your desktop to 640x480x256.

There's a few calls to GetDesktopWindow followed by GetDC, this gets the device context of the windows desktop (being the top level window), so it looks like its, in effect just resizing the desktop to 640x480 then writing directly to it. Possibly. At lot of it relates to dialog boxes and stuff, hard to tell without spending more time. Anyway, anyone who understands standard windows GDI programming should be able to have a go at it...

( all the other stuff still applies, just the 257 code may or may not be what directX uses )

------edit:

Code: [Select]

HRESULT SetDisplayMode(
                         dwWidth,
                         dwHeight,
                         dwBPP,
                         dwRefreshRate,
                         dwFlags       );

... so bne is a wonder of modern technology 

1577

Support Requests / Re: Force change resolution

« on: November 17, 2016, 02:16:19 AM »

i didnt find shiti was changing to 320x240.. dos version (maywork)..i tried 800x600 also..
need lambchops<-----------
just make sure i was doing it right 640 dec to hex 280----->then inputed as 082 correctall !?

hehe. Yes 640 = 0x280

in hex byte display (a la hex editor) the byte order is reversed so as a dword it would be 80:02:00:00

1578

Support Requests / Re: Force change resolution

« on: November 17, 2016, 02:03:35 AM »

there's lots of parts to this question...

I dont think you will find a "640" and "480" setting for screen resolution.

Those numbers will be around as constant values for various calculations to display the graphics, as the entire game is hard-coded for 640x480 screen res.

As for the actual graphics card display, back then 640x480x256 was mode 257 (0x101)
not much point in searching for that value, as you will get anything that has two 0x01 bytes in a row, but if you want to chase down the GL code that sets the graphics mode and change that value you could try
mode 259= 800x600x256 or mode 261= 1024x768x256 colors.

however you will only end up with either the screen still being displayed in a 640x480 rectangle in the corner, or totally mashed into the first 640*480=307200 (0x4B000)pixels of the screen, depending on the method they use to access the graphics hardware.

All the internals are designed for 640x480, for instance if you read the dword at 0x4D4A94 you'll find a pointer to a 0x4B000 byte buffer that holds the current game screen.... you can do a DIY ss by reading these bytes and the 256x3 byte palette from 0x4AE844 then making a PCX or BMP file out of them.

maybe you could just use a generic image resize and display it at higher res, but you havn't really gained anything doing that - you still really have only 640x480 pixels.

To really change the res, you would have to enlarge the buffer (and any others), and change lots of other stuff.

as and example, if you wanted to display a pixel at certian co-ords you would use:
buffer_address + X+ (Y*screen_width)

so for say the location {333,122} you might do ptrScrBuff + 333 + (122*640)

..but in 800x600 you would need ptrScrBuff+333+(122*800), except I think you'll find LOTS of places where the 640 is hard coded... idk never tried to find them. so if you change the display mode and enlarge the buffer to 800x600= 0x75300 bytes, then lots of things... probably the GRP decode routine for starters... would still calculate 333+(122*640), so instead of {333,122} you end up at  {13,98}... then the next row of pixels could end up on the other side of the screen etc.

Not a small job, but I'd love to see it done 

1579

Mods & Development / Re: Nerd's Corner

« on: November 12, 2016, 11:34:07 AM »

1580

Mods & Development / Re: mine distance for claw

« on: November 11, 2016, 04:24:40 PM »

I just cut&paste some bits of gow. Its got 11,12,4,5,s9,s6 and s12 with water and trees round the sides. The zig-zag is s9 with trees on the left.

1581

Mods & Development / Re: mine distance for claw

« on: November 11, 2016, 03:24:07 AM »

Spot the difference 

1582

Mods & Development / Re: mine distance for claw

« on: November 11, 2016, 12:11:09 AM »

...actual gameplay on that map, i dont know why you and maciek joined - it was merely to test that

We were there as UN independant observers trying to make sure no special-needs peons had their rectal sovreignty encroached upon. Shortly after arriving however, it became clear we were already too late. Our deepest condolences go out to the tribes of those affected.

kurwa, i think i will redesign the map anyway

Cool  the idea has some interesting possibilities. Will need a lot of fine tuning to get the balance right, but it could be awesome...

1583

Mods & Development / Re: mine distance for claw

« on: November 10, 2016, 02:45:34 AM »

God dammit blizzard

LAWL

thank u for analysis

np mate

1584

Mods & Development / Re: mine distance for claw

« on: November 09, 2016, 08:09:36 PM »

OK don't have time to write a really good explaination but, in a nutshell, it's calculating distance from the top left corner of the mine.

hall is 4x4
mine is 3x3

hall size is taken into account
mine size is not

units are located where their top-left corner is (you can play with the map editor to see this)

Probably they have re-used code from the unit attack AI to find the closest enemy (with annoy factor).





Its the same thing as the old tower bug, where towers firing up and left would hit other towers that wouldnt fire back, because the size of the destination is being taken into account, but not the size of the source.

In this case you can think of the mine as shooting peons at the hall

As mentioned the distance is what I call "square" distance - the maximum X or Y distance from the top left corner of the mine to the closest point on the hall.

so with that map....




because of the extra 2 squares in the width of the mine, the distance becomes 5 not 3, which is greater than the distance between the halls (which is 4) so in effect they are the same distance, in which case the peon will go for the hall with the lower Y co-ordinate (as they were both on the .PUD, if u built them it would go for the one you built first.

 =D

EDIT:
... this is why you dont see this bug on the other side of the map where the halls are to the left of the mine, because then the distance is only 3, so its less then the Y offset....

 (btw: the calculations on the pic above should have -1 on them, = 5 not 6 , but u get the idea)

1585

Mods & Development / mine distance for claw

« on: November 09, 2016, 05:31:06 PM »

ok first thing I have to say is:

You are absolutely right, kurwa. They are not the same distance, but I still have an explaination for you.

I was concentrating on making sure the distance was 4 between the halls (same as hall width), but of course the minimum distance between mine and hall is 3 not 4.

My bad... not enough sleep...

But I can still explain why. Will post that soon, but wanted to say that as its been more than the 10 minutes i promised.

1586

Mods & Development / Re: Convert wargus stuff to Warcraft 2?

« on: November 07, 2016, 02:55:44 AM »

looks like maybe from the alpha version.

Maybe, but it's still resident in the process for BNE v2.02, although not used.

yeah u'd just want it for a rts engine..with added perks... built in bnet  ,ipx etc.

Yeah, the stratagus guys did some cool stuff, but AFAIK it's still all incompatible with WC2, i.e. you cant play unless all players are using wagus?

speed i still havent found it.
but attacks can be changed and range.

Attacks and range are in the the PUD format, speed is not (attack speed or movement speed).

Also certianly there is no guaranteed attack speed for units. Melee units tend to just hit anything in range, but cats and drags etc. do not necessarily do this. Telling a cat to attack something in range doesn't guarantee it will do it asap. Also peons/peasants move slower when they are carrying.

This sort of thing tends to suggest that the timing of such things is built into the AI, there must still be a bunch of numbers somewhere that at the very least describes a minimum time interval for units taking their next action, but it may or may not be a list for each unit type, as with most unit attributes.

The pathing code advance calculates the next 20 steps for all moving units, then adjusts if that path is blocked, but it does this independantly of the unit's speed, the timing is being dictated somewhere in the core of the engine.

It's facinating stuff, I wish I had more time to look at it right now.

1587

Mods & Development / Re: Convert wargus stuff to Warcraft 2?

« on: November 06, 2016, 04:15:54 PM »

this is kind of interesting...

1588

Mods & Development / Re: Convert wargus stuff to Warcraft 2?

« on: November 06, 2016, 04:07:26 PM »

No worries.

Here's some grps I pulled from process memory, if anybody wants.

(attached 7-zip)

1589

Mods & Development / Re: Convert wargus stuff to Warcraft 2?

« on: November 06, 2016, 01:54:13 PM »

As has been mentioned, Wargus is a completely different program to WC2. It's a ground up re-write ....  fan-fiction, if you will. Its pretty cool, but there is no more chance of anything from Wargus applying to WC2 than stuff from Mario Kart.

Sure, if you put the time into it you could convert some of the graphics to .grp and import them into the game, (and lets face it, that would be freakin AWESOME ) but sadly its not going to give you a boost button or make them jump off a ramp into you opponents base.

As for using 16 players - or at least having units assigned to 16 different players i.e. for rescue and gaining multiple races for each player. This seems to stem from .PUD format allowing for up to 16 players in some sections.

I'd hate to spoil the party, but here's a small bit of info for you.

Player 16 = Dead.
That's where the pixels go when they are punched to death by ogre-magi.

Player 15 is also used for internal purposes. Players 9-14 .... maybe but I doubt they're ever going to function properly, all the player controlling stuff is written for players 1-8.

Pretty much everything apart from the map is a unit, spell effects etc. are units with short lives, but the game engine isn't designed to let you select them or move them etc.

1590

Mods & Development / Re: Server Update

« on: November 04, 2016, 04:43:00 PM »

he was a chop player but i owned his ass

lol, yes suitably glib. But you have more to contribute than just your sense of humor