Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Welshworrier

Members
 View Profile  See their activity

  • Content Count

    471

  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Welshworrier

  1. Posted

    This would be the same individual who just bought some of the st cartridges that you'd probably call "less popular" (which will be of more value to completionists when the carts stop being produced). The same one who was asking for a cheap missile command because he didn't want to pay eBay prices. Who was the subject of the "are these discs fake" thread earlier this month? Etc...

    • Like 2

  2. Posted · Edited by Welshworrier

    Iirc the edge cards were pretty much an R4 card that has the distinction of coming in a triangular box. Last update was in 2010 so the firmware on them predates the launch of the 3ds.

    Tldr version: edge works on ds only, iedge version works on dsi and ds up to 1.4.2 firmware. No version came out that would work on a 3ds or 2ds.

  7. Posted

    What I always found with basic was that as a programming introduction language it was good in that you could quite quickly see the flow of the program and get a grasp on what was needed to achieve the target. However what it was bad at was teaching good coding practices e.g. leading to code reuse and the underlying structures that were needed for larger programs. It worked well when taught in conjunction with one of the other languages (think it was Pascal I learned it with) but didn't really scale up for collaborative projects.

     

    Microsoft, in my mind, bastardised the language when they went to visual basic. It allowed people to get something on the screen quickly without understanding anything about what was going on behind the curtain. This created a series of basic programmers that lacked the nous to actually apply the skills they had to anything outside the visual environment, and in turn led to the maligned reputation.

  15. Posted · Edited by Welshworrier

    That's one part of "DOOM+ bucket list" checked off. :D Now how I'm going to play Jag DOOM with this patched network? :spidey: Thank's Welshworrier and Carl Forhan! :thumbsup: :thumbsup:

     

    You could get two serial to network converters at about 50 dollars apiece. You could then play across the internet if you wanted (as long as the timeouts are okay, probably best to drop to 38400 for that though)
    • Like 2

  16. Posted · Edited by Welshworrier

    Funnily enough it pretty much confirms that the fault was with doom all the time and not the jag. So Atari were right... Unless the DSP was occasionally messing up the positions of course...

     

    The solution of sending more data to fix a networking problem on a suspect serial line is somewhat ironic :)

    • Like 2

  17. Posted · Edited by Welshworrier

    So it now works as post 41 ;)

     

    Congrats on that, glad it's now sorted, I might even buy a jag some time and get to play it :)

     

    The vblsinframe discrepancy comes down to some interesting code BTW, the definition of the variable says it's range is 4 to 8 and code then checks to see if these ranges are exceeded and limits. Well it's supposed to :) the code surrounding the minimum limit has had an if 0 surrounding it to disable that part of the code.

     

    I searched for where the x,y,z positions are actually updated and was surprised to see it's all done in dsp so identifying the point of failure is going to be a bit more interesting.... Though I did like the numerous "f*cking DSP" comments.

    • Like 5

  19. Posted

    Or, using a simple example to demonstrate. If you were at 0,0,10 and moving forward at momentums of x=0, y=2, z= -1. With a vbl of 4 you would be 2*10 forward when you hit the ground. If vbl was 8 then you would end up 2*2*10 forward when you hit the ground. If you modify the z momentum by the vbl as well though you would also end at 2*10

    • Like 1

  20. Posted

    The power of maths compels you!

    If you have a parabolic flight where the rate of descent is different you will end up at different end points when you hit the ground level. I.e. the values of x and y will be different. The different multiplication factor I put it in are necessary because the vbls value vary between 4 and 8. So you divide each of the old values by 4 and then multiply by the vbl to get the value you really need.

     

    I would put money on that being the fault.

    • Like 1

  21. Posted · Edited by Welshworrier

    I take it the error in the code is left for the reader to discover...

     

    I'm guessing the cut and paste error in the recovery where you've copied the x position twice instead of the y position for the second one... (Using 6,7,8,9 instead of 10,11,12,13). ;)

     

    Did you also put in the z fix from my earlier post? Would be interesting to see if the consistency failed then.

    • Like 1

  22. Posted

    Been thinking about the instant kickout too :)

     

    If the consistancy check fails on the first packet (due to the positions of the two players not being setup correctly yet) then you'd get an instant fail - wonder if it's actually needed now if the Z fix works. Using your checksum/retry routine is probably a better option.

    • Like 1

  23. Posted · Edited by Welshworrier

    Been looking again (I do sleep occasionally ;) )

    If you change the code for P_PlayerZMovement to:

    /*
===============
=
= P_PlayerZMovement
=
===============
*/

void P_PlayerZMovement (mobj_t *mo)
{	
/* */
/* check for smooth step up */
/* */
	if (mo->z < mo->floorz)
	{
		mo->player->viewheight -= mo->floorz-mo->z;
		mo->player->deltaviewheight = (VIEWHEIGHT - mo->player->viewheight)>>2;
	}

/* */
/* adjust height */
/* */
	mo->z += vblsinframe*(mo->momz>>2);
	
/* */
/* clip movement */
/* */
	if (mo->z <= mo->floorz)
	{	/* hit the floor */
		if (mo->momz < 0)
		{
			if (mo->momz < -GRAVITY*vblsinframe)	/* squat down */
			{
				mo->player->deltaviewheight = mo->momz>>3;
				S_StartSound (mo, sfx_oof);
			}
			mo->momz = 0;
		}
		mo->z = mo->floorz;
	}
	else
	{
		if (mo->momz == 0)
			mo->momz = -(GRAVITY>>1)*vblsinframe;
		else
			mo->momz -= (GRAVITY>>2)*vblsinframe;
	}
	
	if (mo->z + mo->height > mo->ceilingz)
	{	/* hit the ceiling */
		if (mo->momz > 0)
			mo->momz = 0;
		mo->z = mo->ceilingz - mo->height;		
	}
	
}

    Then the vblsinframe will be used in the Z calculations too.

     

    Edit: slight mod to consistancy check.

    Due to the fact we are only after an 8 bit result it would be better to do as 2 operations.

    tempcons = (tempcons >> 16)^tempcons;
consistancy = (tempcons>> ^ tempcons;

    As we can do a 16 bit xor for the first part

    • Like 1

  24. Posted · Edited by Welshworrier

    If you look at the player movement I believe you might find the issue - vblsinframe is used as a scaling factor to ensure that the second machines movement is the same as the first. This is used for x and y movement BUT NOT Z - falling down or running up could then potentially put you in different position as they would clip at different frames :)

     

    You are not checking position in the consistancy byte and you are getting reliable serial comms with no ACK issues. This, to me at least, is setting off alarm bells.

     

    As the network would normally fail as soon as the positions differed - about 70ms after the occurance (the original consistency check only used the fractional bits of the x/y due to the byte/int issue discussed earlier) then the drifting would not normally have been seen - especially due to the size of the weapons/objects/walls etc and the collision checking - hitting something a gnats tadger to the left/right of where the other console thought it hit wouldn't make much of a difference.

    • Like 1

  25. Posted · Edited by Welshworrier

    Thanks for trying that out for me - annoying it doesn't work :(

     

    Your code looks fine from when I looked at it earlier today and I believe it seems like you've cracked the serial problem, however......

     

    Examining the Doom code shows the way in which the network play is carried out is a bit 'pants' - in effect it plays a two player game on both consoles and simulates having a virtual joypad providing the input for the second player. This of course means that any discrepancies in timing between the two units will affect the positional information for the player i.e. you'll get a drift. The 'consistency' data byte isn't there for packet validation - it's done for positional/graphical consistency to make sure each console thinks the players are in the same positions. The fact there is a specific check for that byte being different and an attempt at network re-negotiation/restart when it doesn't match what's expected reinforces that idea (It would explain why people thought they had a fix over the years but still had it locking up at random times :) )

     

    Can I suggest the following:

    1. send the consistency byte across as before (based on x,y) but calculated correctly

    2. add 8 bytes of data to send only the relevant player0/player1 position information across (2 ints)

    3. add a check to see if the consistency is wrong and if so do a soft recover in setting the second players position to the passed value instead of trying to do a net reset as it currently does

    4. add another byte for packet xor checksum/validation

     

    I realise this will increase the packet size dramatically but seems necessary to remove the final 'feature'

    • Like 2
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...