What are you working on?

[revelator]

Ofc

Your map looks interresting, some upcomming mod or will it be standalone ?

And yep the parallax ocllusion makes stones stand out quite a bit unfortunatly without material support it will be applied to every single surface in game even decals, and that breaks them quite badly.
I hope someone can help me sometime to put proper material supported POM interaction code in idtech4 so we can enable it on select surfaces only.

[Chip]

Anyway I don't care, I didn't post that shot for the FPS counter...

Is it your engine?

[goldenboy]

No, but I thought it was obvious that I was working on a map (see thread title) and was hoping for feedback on that.

Lesson learned, next time I will just disable any HUD elements.

It is an upcoming D3SP with a bit of a mod attached.

[revelator]

My comment was just spontaneus sorry to have derailed you trying to get feedback.

As for the map it looks great

[hogsy]

Working on a cooperative modification for Prey in my free time which is slowly coming along. Hopefully should have something to show of that soon

[mankrip]

Implemented true hi-res screen waterwarping in Makaqu. My previous hi-res waterwarp code did render the scene in hi-res, but the waves of the warping effect weren't scaled up. Haven't posted about it in the blog yet because I still have to take some screenshots for comparison.

Also, fixing a few things in the Windows version.

[mankrip]

I guess most people (outside of here, at least) never noticed how jagged the surface warping effect in the software renderer is:

[ceriux]

i think the one on the left looks better.

[ChOwW]

I'll answer exactly like ceriux, even if the right one seems better to my eyes...

Anyway, in my quest of having a highly "basic" and optimised Quake Engine, I'm analysing the Quake 1 Net_ protocol, both on PSP & PC version, and trying to simplify the code itself.
I also removed any instance of vcrrecording, modem, ipx, so there is only the IPV4 protocol left. (and it's a bit easier to read imho)

Also, all I managed to do is to automatically suggest to host dynamically a server when some conditions are met :

Code: Select all

/*
===================
SV_RunTheServer
TODO:
- Add more conditions:
    * If there is no IP, return immediatly
- Move this code part to Sv_main ?
===================
*/
void SV_RunTheServer (void)
{
//   Q_Print("[SV_RunTheServer] CALLING STATE");
   if (sv.active)
   {
      Q_Print("[SV_RunTheServer] Server already active.");
      return;
   }

   // Activate automatically MP or SP.
      if (svs.maxclients > 2 & sv_gamemode.value != GAME_SINGLEPLAYER ) // solo = -1
         listening = true;
      else
         listening = false;

   // Decide of our network action above
   for (net_driverlevel=0 ; net_driverlevel<net_numdrivers; net_driverlevel++)
   {
      if (net_drivers[net_driverlevel].initialized == false)
         continue;
      dfunc.Listen (listening);
   }
   
        Con_Printf(" [STATE NETWORK] LISTENING STATE ==> %d \n", listening);
}


So in this case, I can safely remove the listen command.

The command will be executed when creating a server (sv_createserver) but there is a huge drawback I've found:
- Changeleveling while having 2 players will take a lot of time (or switching from solo to multiplayer)

------------------------------------------------------------------------------

About the PSP network, I've tested it locally (PC vs PSP, same shared sv/cl source), so as soon as the host (= PC) suggests a changelevel to the PSP, it will keep on "loading" for a minute or a bit more, leading to a "Load Failed." (screen.c) , but it may load the server still, and finally connects to it.

On the contrary, no problems.


Sorry for all those (useless =p ?) explanation of what I was doing, and the eventual problems...

[taniwha]

Actually, I have to agree that the left one looks better. Yes, the one on the right is nice and smooth, but it's very obvious that the texture is low-res. The jaggedness of the left actually creates an illusion that the texture is of a higher resolution than it really is. Now, put a high-res texture in place and the right will look nice

[mh]

I vote for right. If I'm reading this correctly, the individual texels should hold together better on the right-hand one, but it's hard to say without seeing them move.

[leileilol]

It would be faster if the turbulence was on a surfmipblock so it uses the original jagged function for more distanced water. It also makes me wonder why Carmack or Abrash didn't mipmap their water in the first place!!

[ceriux]

the reason i say left is because if you look at the right, the pixels seem to all form blobs of the same color. the one on the left to me seem to show more detail and the right washes it out or blurs the pixels to the same color giving the blob effect i was talking about. the right seems to remove detail that was previously there.

[mankrip]

These comments makes me want to finish implementing this thing for real, instead of #ifdef-ing it out.

I've got to fix a few issues with the MGL-less video interface, but should be able to release this next version soon afterwards. I may look into adding a cvar to enable it.

If I'm reading this correctly, the individual texels should hold together better on the right-hand one

Exactly. And yes, the difference becomes more obvious when animating.

It would be faster if the turbulence was on a surfmipblock so it uses the original jagged function for more distanced water. It also makes me wonder why Carmack or Abrash didn't mipmap their water in the first place!!

What made me want to polish the turbulent texture warping effect were actually the portals, because most of the time they are displayed right in front of our faces when we go to them. In such situations, they can fill the whole screen too close to the camera for any mipmaps to be used.

Originally, afaik, the sole reason for mipmapping was to economize surface cache memory. Turbulent surfaces doesn't go into the surface cache, because... Well, it could be argued that it's because they have no lightmap data, but a slightly modified light tool could solve that. But if the water was lightmapped, the lights on it would also be warped during the rendering, which may have been one factor. Also, with the turbulent surfaces not using the surface cache, the engine can just use their textures directly; and by using the textures directly, the renderer can use constant values for the width and height of the source image, thus speeding up the drawing. Also, afaik, what makes mipmapped surfaces to be rendered faster is the smaller size of their cache (which allows it to be calculated faster); and with the turbulent surfaces using no lightmaps and therefore no surface cache, it becomes unnecessary to use their mipmaps.

And enabling mipmapping on turbulent surfaces would need (among other things) either a different copy of the turbulent spans function for each mipmap level (resulting in absolutely no speed gains), or editing it to use variables instead of constants, which would slow it down. Both alternatives would also require more coding time and more testing. So, there's not much of a point.

the reason i say left is because if you look at the right, the pixels seem to all form blobs of the same color. the one on the left to me seem to show more detail and the right washes it out or blurs the pixels to the same color giving the blob effect i was talking about. the right seems to remove detail that was previously there.

The one on the right displays exactly the same detail that is on the texture. The one on the left (which is the original code) breaks the texture's pixels into smaller parts of irregular sizes; fire up WinQuake, zoom in really close to a water surface and you'll notice.


[edit] As for the jagged version looking better... It can be the case, but only in static screenshots (or when you pause the game). When animating, it looks worse. A far better alternative to add more detail into the image would be to dither the turbulent drawing, but this would make this already very slow code even slower, and I haven't learned to dither the rendering properly yet.

[Seven]

Dear all,

I want to show a short clip about a new Quake monster (see below).
It was a lot of fun to code the new AI, sounds, effects and animations into the game.

A big big Thank you to Psionic. He is the author of this amazing model.

Some facts about its properties:
- 3 different melee attacks
- 1 long jump attack
- 1 ranged attack: Spits out webs that glues the player to the ground for a short (adjustable) time.
- Has an adjustable chance to resist shotguns and nailguns attacks
- Has an adjustable chance of hiding/sneeking inside the ground (= suprise attack)
- Fully adjustable replacement monster for all Quake monsters individually.
Depending on which monster it replaces, its health points and skin texture will change accordingly, to keep the balance of the game !

No new/special maps needed. Works on all maps.
Using DarkPlaces together with its auto_cvar extension to make the above mentioned adjustments for it in-game.
So that the user/player can adjust its appearance to its personal liking.
With fixed values the source can be used for any Q1 engine.

I hope some people will like it a bit. It is quite funny to play against it and its mean abilities.

Youtube in-game clip:
http://www.youtube.com/watch?v=1RUMEjOj ... ature=plcp

Render screenshot:


Kind regards,
Seven