Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Cloudef

Pages: [1] 2 3 4
1
Q-Gears / Re: Q-Gears v0.20
« on: 2011-08-27 21:56:16 »
My makefile and linux fixes should still be there, just run make on the src folder and you get QGears binary to the output folder.
Make sure you have the deps tho.

data/config.cfg shows the keybindings. Just keep in mind that OIS likes to grab a lot of input under Linux, so you need to use the exit keybinding on config.cfg to quit or exit to virtual terminal and kill the process.. Or compile custom OIS like I did.

2
Q-Gears / Re: Q-Gears v0.20
« on: 2011-08-09 19:45:45 »
Yay, for v0.20 \o/

3
Q-Gears / Re: Current state.
« on: 2011-08-03 12:35:47 »
Fixed =)

Great, I also pulled latest changes you've made. Stuff looks great :)

4
Q-Gears / Re: Current state.
« on: 2011-08-03 10:33:51 »
The debug draw issue is because you are returning temporary reference to empty string
Code: [Select]
const Ogre::String&
UiWidget::GetCurrentAnimationName() const
{
    if( m_AnimationCurrent != NULL )
    {
        return m_AnimationCurrent->GetName();
    }

    return "";
}         

To fix, either you should not return temporary reference, and instead return new object. But this isn't ideal solution.
So instead do this (which I believe the compiler you use does, when it notices this scenario).

Code: [Select]
static const Ogre::String NULL_STRING("");

const Ogre::String&
UiWidget::GetCurrentAnimationName() const
{
    if( m_AnimationCurrent != NULL )
    {
        return m_AnimationCurrent->GetName();
    }

    return NULL_STRING;
}         

You also return temporary reference in particle system code. Do you want to me commit these to fixes branch or, just wait until you appear on IRC?
I also compiled custom OIS that does not take over my whole system.

5
Team Avalanche / Re: Midgar Remake
« on: 2011-08-03 00:02:10 »
I can't imagine that's a two mans job. You guys would replace thousands of artists.

6
Q-Gears / Re: Current state.
« on: 2011-08-01 18:32:09 »
Wait until G finished his exporter. He write psf with posibility to execute any needed line of AKAO script and with save to ogg files.

You can write first version of sound playback.
It must read separate file sounds.xml with name and filename in it. For now only play once (i don't know it it will be ever needed for loop).

play with AudioManager::PlaySound( const Ogre::String& name );

There must be few sounds that can play togather (20 for example). if more than that - write warning to log.

Ok sounds cool, I'll pick that up later.

awesome! im gonna have to try again on my nix machines. be sure u haven't done anything to break it for debian. also the sound effects iirc are just wave files stored in an archive.there is a tool to extract them around here some where so im guessing someone knows how to read this format

I use Arch Linux myself. The makefile isn't yet complete, but should do it's job for most of distros, by just typing make (assuming you have all deps). The latest hg is broken on linux however cause the debug draw code is poking on uninitialized strings, to workaround this, disable ui_debug on config.cfg. I'll pinpoint what's wrong with the debug draw later. (Also the Linux fixes are in linux branch, or you could just apply these yourself.. Check my last post above.. It's nothing big)

7
Q-Gears / Re: Current state.
« on: 2011-08-01 15:44:18 »
Ok, Linux fixes + makefile are on Linux branch now.. And AudioManager is there on Audio branch. It handles just ogg files for music ATM. You said something about sound effects needing reverse engineering? They are not yet documented on Qhimm? (I suck at Reverse engineering )

8
Q-Gears / Re: Q-Gears v0.19
« on: 2011-07-30 14:20:57 »
I use Gentoo and I could compile qgears when fix project file. But source code contain such lines which cann't work under Linux:
Code: [Select]
#ifndef _DEBUG
    root->loadPlugin( "RenderSystem_GL.dll" );
#else
    root->loadPlugin( "RenderSystem_GL_d.dll" );
#endif

I've fixed this, whenever I'll get contact with Akari, I'll discuss about possible changes to make it more Linux friendly (Eg. use SDL instead of OIS for input and such)

9
Q-Gears / Re: Current state.
« on: 2011-07-30 13:59:51 »
We probably live on really different timezones, anyways..
I fixed code bit to compile on Linux, also made nice makefile
Code: [Select]
####################################################################
#                                                                  #
# Q-Gears                                                  #
#                                                                  #
# Depends : OGRE, OIS                                  #
# Internal : lua, luabind, tinyxml #
#                                                                  #
# make DEBUG=1 - Debug                                         #
# make - Release #
#                                                             #
####################################################################

# Useful stuff, for eg. cross-compiling
INCLUDE_DIR  := /usr/include
OGRE_INCLUDE := ${INCLUDE_DIR}/OGRE
OIS_INCLUDE  := ${INCLUDE_DIR}/OIS
LIBS := `pkg-config OGRE OIS --libs`
DEBUG := 0

# ---- Q-GEARS Specific ----
CORE_DIR := core
VIEWER_DIR   := viewer
QGEARS_BIN := QGears
BUILD_DIR := ../output

# ATM there is no intelligent render system selection,
# so put your rendersystem path here and it gets copied to build dir
# with name "RenderSystem_GL.so" or "RenderSystem_GL_d.so" in debug mode
OGRE_RENDERER := /usr/lib/OGRE/RenderSystem_GL.so

# ---- Libs that come with Q-Gears ---
INTERNAL_LIB_DIR := ${CORE_DIR}/library
LUA_DIR := ${INTERNAL_LIB_DIR}/lua
LUABIND_DIR := ${INTERNAL_LIB_DIR}/luabind
TINYXML_DIR := ${INTERNAL_LIB_DIR}/tinyxml

# If you set these to 0, we will try to use system libs instead
BUILD_INTERNAL_LUA := 1
BUILD_INTERNAL_LUABIND := 1
BUILD_INTERNAL_TINYXML := 1

# Define libs for these if you don't want to build them
# Default values are just a guess, there is no quarntee all of them come with pkg-configs
LUA_LIB = `pkg-config lua --libs`
LUABIND_LIB = `pkg-config luabind --libs`
TINYXML_LIB = `pkg-config tinyxml --libs`

# ---- A.I ----
# Intenal libs should be build before anything else.
ifeq (${BUILD_INTERNAL_LUA},1)
SOURCE += $(patsubst %.c,%,$(wildcard ${LUA_DIR}/*.c))
else
LIBS += ${LUA_LIB}
INCLUDES += -I${LUA_DIR}
endif

ifeq (${BUILD_INTERNAL_LUABIND},1)
SOURCE += $(patsubst %.cpp,%,$(wildcard ${LUABIND_DIR}/*.cpp))
else
LIBS    += ${LUABIND_LIB}
INCLUDES += -I${LUABIND_DIR}
endif

ifeq (${BUILD_INTERNAL_TINYXML},1)
SOURCE += $(patsubst %.cpp,%,$(wildcard ${TINYXML_DIR}/*.cpp))
else
LIBS    += ${TINYXML_LIB}
INCLUDES += -I${TINYXML_DIR}
endif

ifeq (${DEBUG},1)
DEFINES += -D_DEBUG
endif

# ---- Build defines ----
SOURCE   += Main.cpp \
$(patsubst %.cpp,%,$(wildcard core/*.cpp))    \
            $(patsubst %.cpp,%,$(wildcard core/particles/*.cpp)) \
$(patsubst %.cpp,%,$(wildcard core/particles/emitters/*.cpp)) \
$(patsubst %.cpp,%,$(wildcard core/particles/renderer/*.cpp))
DEFINES   += -DTIXML_USE_STL
INCLUDES   += -I. -I${VIEWER_DIR} -I${CORE_DIR} -I${INCLUDE_DIR} -I${OGRE_INCLUDE} -I${OIS_INCLUDE} -I${INTERNAL_LIB_DIR}
TARGET = ${BUILD_DIR}/${QGEARS_BIN}
OBJ = $(addsuffix .o, $(basename $(SOURCE)))

all: ${TARGET}
@true

# Ugly CPP
%.o : %.cpp
${CXX} ${CXXFLAGS} ${DEFINES} ${INCLUDES} -c $^ -o [email protected]

# Good old C
%.o : %.c
${CC} ${CFLAGS} ${DEFINES} ${INCLUDES} -c $^ -o [email protected]

# Link, create build dir if does not exist
${TARGET}: ${OBJ}
mkdir -p "${BUILD_DIR}"
${CXX} $^ ${LIBS} -o "${TARGET}"

ifeq (${DEBUG},1)
cp "${OGRE_RENDERER}" "${BUILD_DIR}/RenderSystem_GL_d.so"
else
cp "${OGRE_RENDERER}" "${BUILD_DIR}/RenderSystem_GL.so"
endif

# Note: Don't clean ${BUILD_DIR} it's generally non good idea for deveploment
clean:
${RM}  ${OBJ}
${RM}  "${TARGET}"

# TO-DO
# Note: Use ${PREFIX} for install location
install:
echo "Not yet implented"
^ Formatting fails, yay

Code: [Select]
#ifndef _DEBUG
#  ifdef __WIN32__
      root->loadPlugin( "RenderSystem_GL.dll" );
#  else // Assume Linux for now
      root->loadPlugin( "./RenderSystem_GL.so" );
#  endif
#else
#  ifdef __WIN32__
       root->loadPlugin( "RenderSystem_GL_d.dll" );
#  else // Assume Linux for now
       root->loadPlugin( "./RenderSystem_GL_d.so" );
#  endif   
Also Linux version of RenderSystem loading, just copy the .so from /usr/lib/OGRE/RenderSystem_GL_.so, or if you use the makefile it does this automatically.

Next... I suggest we get rid of OIS and use SDL, since OIS pretty much crap everywhere expect Windows.
The only downside would probably be that OGRE depends on OIS and needs to be linked with it, but the app would not use it.

If you allow me to do this, I can do the changes. They are not big if you are OK with only supporting OGRE 1.6 and later, with older OGREs you need more hackery to support SDL input.

10
Q-Gears / Re: Current state.
« on: 2011-07-29 22:28:54 »
Quote
Ohayo for you too =)
I use gtalk, iCQ and skype. You can set up channel in IRC and post it here - I join )

Sure, I'll do that tomorrow. #q-gears @ freenode.net sounds good? I don't have particular love interest to Ogre, especially after porting it and it still does not work that well.
So yeah tomorrow, I'll clone then the work you've done and get familiar with the code. You can fill me more details on IRC then.

E:
Ok, I'll idle at that channel from now on. Whenever you pop there, highlight me to get attention.

11
Q-Gears / Re: Current state.
« on: 2011-07-29 16:26:35 »
\(^o^)オハヨウ!!!

I just ported OGRE && Irrlicht to OpenPandora, both GLES 1.1 and GLES 2.0 renderer works, tho GLES 1.1 is slightly faster since fixed pipeline is more optimized on driver. I had to alter irrlicht a lot however, since it uses lots of 64bit variables for calculations which are performance killer on many ARM mobile platforms. OGRE port was straight port since it happenned to have floating point precision on compiling settings and seems to work good apart from some texture issues, which I will solve soon.

Whenever I get Pandora(if ever) for myself. I might consider taking contact at you again, since I've been got much more experienced under C (and C++ too)

Also, Akari do you use IRC? I dint really like the IM last time :)
IRC would be great place to lurk and actual contribute something when interesting discussion gets caught.

12
This is the place where you are supposed to do your first grinds.

13
Q-Gears / Re: Current state.
« on: 2011-04-29 09:47:06 »
I would suggest changing to Git, and hosting on github or so.

14
Completely Unrelated / Re: IT'S OVER! SONY IS FINISHED!
« on: 2011-04-27 16:50:58 »
Quote
yes i have read you post again in you post you clearly state that open-source software is the way to go because you will own it. this however is NOT TRUE as you don't have any rights to it by default, since its not coved by the GPL(or a compatible free liscense). the creative commons is a joke when it comes to software, you get the source code but you CAN'T do anything with it. read some different lisences some time and see how the gpl protects user rights(the 4 freedoms) and "open source" does nothing more then give you some source code that you can't really do much with.

Where is the facepalm when I need it.

15
Completely Unrelated / Re: IT'S OVER! SONY IS FINISHED!
« on: 2011-04-27 14:33:24 »
like most ppl you have confused the terms you want FREE software as free software includes a free license (gpl,lgpl) open source softwre does not have to have ANY freedom associated with it.

read more below
http://www.gnu.org/philosophy/free-software-for-freedom.html

No.. Read my post again.

16
Q-Gears / Re: Current state.
« on: 2011-04-27 14:31:47 »
I read some articles about Javascript VS Lua. And I really don't sure about results. Sometimes Lua faster, sometimes javascript. But Lua is language heavy used by game industry. It uses very little space, has no dependancies on other library and quite fast while has really lot of power. I think we stick with it. Just want to wait until they release 5.2 )
Though I can use 5.1 with bitlib right away.

Yeah, better with familiar than odd one.

17
Q-Gears / Re: Current state.
« on: 2011-04-27 11:15:57 »
Those libs sound good, about ogre.. I've never really liked it much, it depends on it's core parts too much, and it makes code look bit ugly.. Well the reason for this might be since I've quite strayed away from C++ to C.

Have you tried Javascript instead of lua btw? Those have blazingly fast VM's.

18
Completely Unrelated / Re: IT'S OVER! SONY IS FINISHED!
« on: 2011-04-27 09:43:20 »
Nowadays business model :
Buy something, yet still don't own it.

Open source is still the way to go, it seems.

19
Q-Gears / Re: Current state.
« on: 2011-04-27 09:34:06 »
So, what are the libs you are going with Akari? Ogre, OpenAL?
I have experience with OpenAL (Well, with a wrapper from Penumbra), but I've avoided Ogre to speak the truth.

The UI in 3D benefits from GPU too, well this can be done with sprites too... But like Akari said they could cause distortion when scaled and so, meaning same 2d elements for different resolutions. Unless you construct the UI from parts.

20
Team Avalanche / Re: Project Bombing Mission Gallery
« on: 2011-04-26 23:37:25 »
You're a damn good 3d artist.

21
Open world where everything gets repetive and you start to feel like there is nothing to do, Bad character designs (Or ugly character parts for creation), bad story, clichéd drama (This is everywhere), usually bad gameplay elements..

So yeah.. Most WRPGs are bad just like any other game. It does not matter what genre, all it has to be is a good game.

22
Q-Gears / Re: Current state.
« on: 2011-04-09 17:27:39 »
Really what are those?
Yes I believe that I mentioned that darkbasic is directX... :-\

Well first of all it is basic language, so you need to do everything the hard way (Even if it's simpler) It lacks some features in language what even C has.

Next, even if it has lots of stuff like physics and so on, they are all slow. Heck I'd know since I started programming with dark basic professional :P

23
Q-Gears / Re: Current state.
« on: 2011-04-09 11:15:48 »
Darkbasic is language, it's OK for new programmers or hobbies, but It's going to lack in features Akari is going to need, and is going to be damn slow also. It isn't cross-platform either and you get the idea..

Others that I imagine being no-go are XNA and such, they suck and aren't cross-platform. There are quite few OSS rendering engines which is quite sad. Reason why I pick'd up raw OpenGL.

24
Q-Gears / Re: Current state.
« on: 2011-04-07 15:09:49 »
Since it is Irrlicht now, I can maybe start hacking it on my freetime too.
However It's not that hard to do own OGL renderer also, (I've come quite far with C/C++ and OpenGL since we last time talked)




But yeah, irrlicht seems like best bet to go, so don't need to fiddle head with renderer framework design and other things.
However Irrlicht has been also quite dead nowadays and seems to have some annoyances.

25
Touhou, touhou and touhou.

Pages: [1] 2 3 4