emajekral
-
Content count
110 -
Joined
-
Last visited
Posts posted by emajekral
-
-
Middle click & drag: I don't see how this can work because currently, when you middle click & drag you rotate the camera.The camera wouldl still rotate, but the range of the rotation would be greater with no or minimal drift after. Currently rotation stops when the mouse cursor hits the edge of the screen. With the proposed change the mouse would switch off or fo to the middle and the rotation would be free. The mouse would be restored to its former location when the drag is done and the mouse button is released.
I don't get it at all, sorry
Currently you click with the middle mouse, hold it down, drag a little(doesn't have to be to the edge of the screen), move your mouse to the side and when you let go you can have it spin around a lot or a little, depending on how much you move your mouse cursor. Anyway-this is click and drag, i wouldn't know how else to explain the current camera rotation.
Sorry. I'll try to be clearer.
The proposed change is this:
- allow full and unlimited control of the camera for as long as the middle mouse button is held.
- other than the fact that the cursor would no longer move when dragging you would not notice the difference.
Extra changes:
- allow the user to configure how long the spinning persists after letting go.
- apply the desired behaviour to the right mouse button instead of the middle because it is usually larger and easier to hold down.
- to allow right click action switching and right drag camera motion to coexist you only switch current action if a total motion of less than x pixels occurred. (Where x is ~ 5)
If this isn't clear enough I can try to make a demo video. But that means compiling the client in Windows. *shudder*
-
Still no reflections with frame buffer onI've never had luck with reflections with the frame buffer on (in Linux). It was one of the in game issues that made me start working on the client.
-
Middle click & drag: I don't see how this can work because currently, when you middle click & drag you rotate the camera.The camera wouldl still rotate, but the range of the rotation would be greater with no or minimal drift after. Currently rotation stops when the mouse cursor hits the edge of the screen. With the proposed change the mouse would switch off or fo to the middle and the rotation would be free. The mouse would be restored to its former location when the drag is done and the mouse button is released.
-
OK. I've compiled the client
First thing I've noticed is that when you middle click the cursor it stays visible and moves all over the screen when you look around. I just finished a week of playing World of Warcraft and I believe that's the direction I would like to camera manipulation go:
Middle click: no effect
Middle click and dragr: cursor goes into temporary mouse grab mode: cursor is centered or hidden, range of motion is unlimited.
As a bonus the same behaviour could be implemented for right click and drag. I find it MUCH easier to drag with my right mouse button cause my mouse wheel is so tiny. Is this a desired change? The change is simple.
Second, floating banners for XP and levels are all messed up. That should be an easy fix - however I lost all my old code in September when I had to do a system restore... I wasn't backing up my EL stuff.
Third, I would like to help troubleshoot the flickering stars, moon and indoor skies issue too BUT I can't see the problem. What compile/in-client options and hardware/OS are you using when the glitch appears?
Grab mode and follow mode are supposed to be mutually exclusive. Turning one on should turn the other off. I just never got around to fixing it.
Fedora: I'm not trying to edge you out. I really don't have a lot of time for this. The fact that I came back right when you started working is coincidence: my WoW trial expired, I got all nostalgic for EL and I got inspired by some of what I saw over there.
-
Hi. I'd really love to see this work make it into the client. Thanks for taking over. I think I see a few odd changes. It's reading week at Uni so I might have an opportunity to post some fixes. If I post anything it'll be the odd line here and there posted in this thread. You can ignore me if you like.
I'm currently mucking around with a character named Mort_Emer if you want to contact me.
-
ttlanhil:
It's really hard to find the right balance between family, learning, work, play, and charity. For me EL is learning and charity all in one. It used to be play too, but things change. I still think the game is great, it just doesn't fit my lifestyle now.
Know that I appreciate what you've done. Good luck and maybe we'll be logged in at the same time some time... not that I'll ever have anything sensible to say.
Roja:
On sky gradients
- There's a sky gradient on at all times. At night it becomes indistinguishable from the fog. At the moment the sky gradient is uniform in all directions, but there's no reason why it has to be, it was just easier that way at the time.
Regarding moonlit clouds
- Yes it's possible to light up the fringes of clouds around the moon, it was on my TODO list right after "Make two moons that have a regular cycle that is syncronised to in game date and time" but that's about where I started making random changes and ran out of energy and time.
Let the artists be free
- One of the things I was planning to do was put the variables that control the sky's appearance in a file and load it up whenever the map changes. This would eventually allow the client to check to see if there's a special sky configured for a particular map and do things like:
- change the angle of the sky to simulate latitude
- load special cloud textures
- change the moons' sizes, colors, textures
- switch to a more appropriate sky engine like is done for the underworld and interiors.
- change the angle of the sky to simulate latitude
Give me a couple of weeks and I'll see if I can come up with a config file format for skies so you can play around with them Roja.
I may also put in some hooks that can enable server initiated moon color changes for special events if someone on the server side wants to do that (I seem to recall that being a request).
I won't write the message parsing code, just provide functions for other programmers like:
//change moon 0 or 1 to color over transition_time seconds void specialMoon(int moon_num, int transition_time, float color[4]); //change moon 0 or 1 back to its normal color over transition_time seconds void resetMoon(int moon_num, int transition_time);
I haven't compiled the client or played since I last posted here so I'll comment more when I have had a chance to do so.
- There's a sky gradient on at all times. At night it becomes indistinguishable from the fog. At the moment the sky gradient is uniform in all directions, but there's no reason why it has to be, it was just easier that way at the time.
-
I have packaged the latest and greatest versions of the three SDL libraries we use in the project.
Here are some temporary links:
If you have followed the official compile guide then you can get things working easily:
- open the DevCpp package manager (Tools>Package Manager)
- remove the 3 SDL packages you find there
- download all three packages in this post and install them
I have tested these packs as described and from a clean install. Everything *should* work for you. Let me know if any thing goes wrong.
There were some errors in CVS at the time I first wrote this. See this for details. I think they are fixed now.
edited for clarity
- open the DevCpp package manager (Tools>Package Manager)
-
While testing new SDL devpaks for DevCpp I had to change today's CVS code as follows:
added this to misc.c:
#include <SDL_thread.h>
on line 47 of platform.h I changed this:
#define snprintf sane_snprintf
to this:
#define snprintf safe_snprintf
and I still get this warning (but a usable compile because the correct function signature is in an object file somewhere)
e3d_io.c [Warning] implicit declaration of function `safe_snprintf'Looks like my new devpaks work. I will post them to the compile help thread in a moment.
-
Heads up about a Linux-y compile issue:
For the first time ever I had to add -lGLcore to successfully link the client.
I use Fedora Core 6 with nvidia drivers and livna repositories. I have seen complaints of errors like mine on message boards from users of other Red Hat based distros. This is likely related to some Fedora update funkiness... EL code that I was working on compiled one month and not the next with only a few "yum update"s in between.
The errors I got were all about missing symbols like _nv#### (can't remember the exact numbers).
edited for spelling and clarity
-
I just re-read my code fix. What I said is wrong. What I meant is right. Get rid of the -(first_person?35:0) bit and leave the rest of the line in place.
I imagine that the 35 degree correction was intended to allow the camera to look up when not using extended camera while in first person mode. I was going to force extended camera mode eventually.
-
Hi all. Glad to see this merged with CVS. It looks great considering how I just dumped it in ttlanhil's lap and all. I compiled it today and things look OK. Just a few things:
- The FPV camera is too high now (with extended camera on. The height is correct when it's turned off.). The original height had it centered right behind the bridge of the nose: precisely where your eyes would be if you were your character. Now it looks like it's just above the top of the character's head. I know there was discussion about this... just my thoughts. One reason why the camera looks odd when its lower is that some of the objects in the game are oversized compared to the players.
- I put the extended camera option in so that those that insisted on using the old UI could easily enable it.
- Turning extended camera on without using FPV should be close to but not quite the same as the early client I sent Roja. I don't quite remember what values I used for that - I tweaked them so that you could grab the mouse and click just in front of the character. Probably changing the magic number in draw_scene.c:218 from -1.6f to -2.0f will make it match her memory - a little higher than the classic EL and a little lower than what I delivered. This screenshot is with -2.0f.
- The sky in FPV in CVS right now is tilted 35 degrees... horizon fog is in the wrong place and shadows are all wrong. The offending line is draw_scene.c:270
glRotatef(rx-(first_person?35:0), 1.0f, 0.0f, 0.0f);
That line shouldn't be there at all. Removing it fixes the bug for me. Sorry. I don't generally use the trinary operator so I'm not sure how that got there. - When I checked the client out of CVS 3 hours ago sky.c needed to include SDL_active.h to compile.
Keep up the great work. I appreciate what you've done.
- The FPV camera is too high now (with extended camera on. The height is correct when it's turned off.). The original height had it centered right behind the bridge of the nose: precisely where your eyes would be if you were your character. Now it looks like it's just above the top of the character's head. I know there was discussion about this... just my thoughts. One reason why the camera looks odd when its lower is that some of the objects in the game are oversized compared to the players.
-
Yup. It's stuff like that that kept me from committing. And levelling. I kept watching the stars, sun moon, clouds, etc. I currently do NOT recommend using alt-g to grab mouse. It hasn't been maintained since August last year. The correct way to grab and release is middle mouse. If you don't have one you're missing out.
For now some issues can be resolved by changing these lines in gl_init.c:
if (!sdl_cursors) { SDL_ShowCursor(0); SDL_WM_GrabInput(SDL_GRAB_ON); }to
if (!sdl_cursors) { SDL_ShowCursor(0); SDL_WM_GrabInput(SDL_GRAB_OFF); }That block was a quick fix from just before I submitted and I got it wrong. (It's still wrong, just less so.)
-
Take a look in C:\Dev-Cpp\lib\
if you don't see alut.lib and alut.dll in that directory then you need to download this file and install it with the Dev-C++ devpak manager.
you may need to look at the list of packages listed under Tools>Package Manager to see if there's a conflicting version of alut installed.
Roja, I changed some of the libraries and many of the instructions for setting up Dev-C++. Unless you've followed the corrected directions from this link closely in the last week you will have undefined reference errors.
-
I'm not sure about the sound errors but the load_map error will be fixed if you look in the subdirectory called io and add all the code files you see there to your project.
load_map is in elc/io/map_io.?
Make sure you look in all the folders in your cvs checkout and include any .cpp, .c, and .h files you see.
alutLoadMemoryFromFile is in the alut.lib library file. Make sure you have installed the freealut devpak and have added
C:\Dev-Cpp\include\AL
and
C:\Dev-Cpp\include\SDL
to your include directories.
If you haven't done so before now Rebuild All (grey broken window icon)
_____
Perhaps the Makefile is easier? This is why I haven't put these instructions in my guide yet.
-
That's what I get for not doing a proper compile guide. I tested that one last night. leave -lelc out of the list you paste into linker (post above has been edited apropriately.)
-
Thanks for taking this on ttlanhil you RULE.
Here's a video of the corrected stuff you can all look at until it hits CVS: You Tube Rocks.
The corrections I mentioned in the video are:
in stats.c, this function:
void draw_floatingmessage(floating_message *message, float healthbar_z) {change
draw_ortho_ingame_string(x, y, 0, message->message, 1, font_scale*0.14, font_scale*0.21);
to
draw_ortho_ingame_string(x, y, 0, message->message, 1, INGAME_FONT_X_LEN*font_scale, INGAME_FONT_Y_LEN*font_scale);
wherever it occurs (twice near the end of the function).
-
A quick note - and something I'll add to my How to soon.
To get Dev-C++ to compile without the provided makefile paste this into BOTH the compiler and C++ compiler boxes in the parameters tab in the project options window.
-DWINDOWS -DELC -DAFK_FIX -DALPHA_ACTORS -DATI_9200_FIX -DAUTO_UPDATE -DCOUNTERS -DCUSTOM_LOOK -DCUSTOM_UPDATE -DEYE_CANDY -DFONTS_FIX -DFUZZY_PATHS -DIDLE_FIX -DMASKING -DNEW_ACTOR_ANIMATION -DNEW_ALPHA -DNEW_TEX -DNOTEPAD -DOPTIONS_I18N -DSFX -DSIMPLE_LOD -DUSE_INLINE -DZLIB
Paste this into linker:
-lstdc++ -lpng -lz -llibxml2 -lSDL_net -lSDL_image -lsdl -lalut -lopenal32 -lglu32 -lopengl32 -liconv -lvorbisfile -lvorbis -logg -lcal3d -lm
and make sure you include all .c .cpp and .h code in your project... even the stuff in subdirectories. Especially make sure to look in the eye_candy and io sub directories.
If you are in doubt, try the provided makefile once, then look at the compile log. From the final compile line copy all the -D things into compile options, and all the -l (little L) things into linker options. Check out make.defaults for more options. Any FEATURES can be added to the compiler options with -D in front of them.
-
Torg: No, the culprit appears to be Eye Candy... There's some interesting lines of code in ec_idle (sp?) that appear to muck with camera_[xyz] then store the results back to actor (don't have the source on me right now).
I know it's something from after January that caused the problem 'cause last time I hacked at the client it was after merging with fresh CVS on Feb 4th 2007.
-
Resurrecting this topic.
Whoa! Lots of changes in the client and I'm adding more.
I plan to hand off everything I've done as soon as everything I did is back to where I remember it.
I just finished kludging the new camera angles back to where I remember them being. me->tmp in gamewin.c:move_camera() is no longer centered on the player - the camera offset has been added to it and that change interfered with my stuff.
I hope whoever takes over my stuff knows who played with the camera besides me and can de-kludge my stuff. It was bad enough as it was.
-
you can unselect the eye candy C++ wrapper files as wellActually I believe you can now leave the cal3d wrapper in the selection list. I'll test that and remove that instruction if it isn't needed anymore. It was only there to avoid the hassle of making exceptions and compile rules for C++ when Dev-C++ was generating makefiles.
It might be worth adding this to your instructionsI may add that change and the one to add an icon to the .exe (and maybe the one to strip binaries too) to a "Advanced Aspects and Refinements" section. I'll think about it.
-
Forum Name/ingame name: Emajekral/Ezzat or Emajekral
Environments in order of readiness:
IDE: Dev-C++
Compiler: gcc version 3.4.2 (mingw-special)
Make: GNU Make 3.80 This program built for i686-pc-mingw32
OS: Microsoft Windows XP
IDE: emacs, vim
Compiler: gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)
Make: GNU Make 3.81
OS: Fedora Core 6
Linux******** 2.6.20-1.2925.fc6 #1 SMP Sat Mar 10 19:15:16 EST 2007 i686 i686 i386 GNU/Linux
IDE: Visual Studio 2003 .NET
OS: Microsoft Windows XP
IDE: Visual Studio 2005
OS: Microsoft Windows XP
Sometimes I compile my patches in linux, but not too often any more. I use the dev-c++ route.
-
gcc -march=i686 -Wall -O0 -ggdb -pipe -DWINDOWS -DELC -DAFK_FIX -DALPHA_ACTORS -DATI_9200_FIX -DAUTO_UPDATE -DCOUNTERS -DCUSTOM_LOOK -DCUSTOM_UPDATE -DEYE_CANDY -DFONTS_FIX -DFUZZY_PATHS -DIDLE_FIX -DMASKING -DNEW_ACTOR_ANIMATION -DNEW_ALPHA -DNEW_TEX -DNOTEPAD -DOPTIONS_I18N -DSFX -DSIMPLE_LOD -DUSE_INLINE -DZLIB -fno-strict-aliasing -IC:\\Dev-Cpp\\Include\\AL -IC:\\Dev-Cpp\\Include\\SDL main.o -L. -lelc -lstdc++ -lpng -lz -llibxml2 -lSDL_net -lSDL_image -lsdl -lalut -lopenal32 -lglu32 -lopengl32 -liconv -lvorbisfile -lvorbis -logg -lcal3d -lm -lstdc++ -o el.exe
That means everything worked perfectly! Yourr executable is el.exe. Copy it to a game directory double click and play!
-
If you modify a file intentionally or unintentionally then a CVS update will not fix that file. It marks it M for modified instead of U for update. If you ever do a build without including the Makefile.win, Dev-C++ will overwrite the one from CVS and it will never be fixed. Possibly simply deleting the Makefile.win and then updating will resolve many problems.
The directions I have posted are not intended to resolve deep set problems, they are meant to be used from scratch. Every time I update them I uninstall Dev-C++, delete my CVS checkout directory and follow the whole thing through 3 or 4 times noting problems I encounter along the way.
-
I don't know if I am going to put this in the official guide but this does the trick:
Change the instructions for the $(EXE) target in Makefile.win to this:
$(EXE): main.o $(TMP_LIB) windres elc_private.rc elc_private.o $(LINK) $(CFLAGS) $< -L. -lelc $(LDFLAGS) elc_private.o -o $(EXE) strip -s $(EXE)
Please note that the leading whitespace on each of those lines should be a <tab> character not spaces.
If you wish to use the debugger comment out the strip line like this
# strip -s $(EXE)
@Placid: Done
Skybox discussion
in Programming
Posted · Report reply
Two small fixes here:
In actors.c remove these lines from draw_actor_banner:
In the same function find this line:
immediately after it insert
#ifdef SKY_FPV_CURSOR if (!((first_person)&&(actor_id->actor_id==yourself))){ #endif /* not SKY_FPV_CURSOR */Near the end of the same function find these lines:
change them to this
In stats.c find this line in draw_floatingmessage:
I can't remember the last half but it should read this instead:
Awesome.
No solution would be simpler than extending the visible edges of the maps in the map editor. Approximately 20 extra tiles in visible directions should suffice. The fake horizon fog in sky.c draws solid fog color (sort of) for 5 degrees above and below the horizon. That would make the sky's fake fog touch real fog at around 20 tiles past where the character is standing. I think. I'll play with the map editor to see if that works then make a firmer recommendation.
It might be possible to eventually extend the map editor so that you can specify an "infinite" edge that could be handled in the client: ie. it could automatically fill past the edges of the map in accordance with a vector plot of what lies past the edge of the map.
The only shaders that complain at me are some of the texture compression ones (GeForce 6800). With NEW_SHADER enabled I see a spin box for reflection detail, but it doesn't work. Perhaps I should see the thread where it is introduced before proceeding.