Page 3 of 3
Posted: Fri Jun 09, 2006 2:27 am
by AndyCR
it can be easy or hard. if you take time to learn it's intracacies, it can be a hard language, but if you just want to fiddle with the rf1 scriptset, say add a new entity thats simple, it isn't too hard. it's almost as easy as simkin (rf1's scripting), but it offers better flexibility. the hard part is remembering how to use the language and how to use all the features of the scripting.
then again, I'm probably biased, I work with c++ for rf2 every day for several hours, which is one of the harder languages; another user after i give a beta test should be able to give an unbiased answer.
Posted: Fri Jun 09, 2006 4:45 am
by Cynnical
yea im a c++ guy myself so thats why i was wondering =)
Posted: Sat Jun 10, 2006 12:56 am
by AndyCR
Ah. In that case, it won't be a problem at all.
Well, I have the setup portion done except for polish. Example Python code:
Code: Select all
reader = inireader.IniReader('RealityFactory.ini')
try:
rfsetup.setdriver(determinedriver(reader.readfield('Driver')))
except(ValueError):
rferror.reportfatalerror('Field \'Driver\' in file \'RealityFactory.ini\' names an invalid driver.')
As you can see, the python code interfaces with RF2 itself in many ways.
I also finished coding the object that you will use to define 2d screen positions in python... you can use it like:
Code: Select all
import rfobjects
...
screenposition = rfobjects.position(100, 200)
screenposition.x += 100
And so on. I will be making a dimension type that is exactly the same except instead of x and y it has width and height for defining things like the screen size in setup.py, and so on, ie:
Code: Select all
rfsetup.setresolution(dimension(800, 600))
Posted: Sun Jun 11, 2006 3:54 am
by MakerOfGames
RF2 release?
AndyCR wrote:It definitly will not be this year.
Thats a little dis-heartening to hear that such a great sounding upgrade to RF is so far off. Well... I hope we can get more volunteers to help. I want to but I dont know anything more than old visual basic. I got the 2005 express edition and cant figure out keypresses or call command, both I could do before, so I have been outdated and thus the use of the word "old" above. Anyway....
Best of luck to the RF2 dev team. Keep up the good work.
Posted: Sun Jun 11, 2006 3:02 pm
by GD1
wow! python is really an impressive system. I've worked with it in blender and some of those scripts are pretty advanced.
when i was involved with blender i remember there was a significant speed lose caused by using the python system. the whole setup for reading the scripts was very slow. has this been resolved in the newer version?
Posted: Sun Jun 11, 2006 9:05 pm
by Jay
I think there also should be some kind of preloading/caching of scripts in RF2 because otherwise the performance will break down to pieces.
But wait! I think Nebula used Phyton scripts too. I may be wrong though.
Posted: Sun Jun 11, 2006 9:24 pm
by AndyCR
Yes, I was worried about it too. However, since Reality Factory 2 uses one of the fastest 3D engines, I hope they will cancel each other out. I'm sure there will be SOME performance hit, but IMO it will be worth it.
Yes, how I plan for it to work is this:
- Script is loaded from disk, into memory
- Everything but the frame() method is kept as a string
- The frame() method, which is called on all objects every frame if present, is converted into a native Python object for fast execution
(That's the plan, anyway. I need to see what Python supports.)
Posted: Mon Jun 12, 2006 2:19 am
by AndyCR
Wow. This is one heck of a coding trip... New motto for Python:
Simplifies your life... Unless you wish to extend it.
In reality, I imagine it is actually somewhat tame compared to many libraries, I've just been lucky and not had to deal with your hairier libraries, and Irrlicht has been a little too good to me...
Aside from that, it's going well. Just a bit slow. I had to learn a new programming language, learn how to embed it in another program using a different programming language, and learn how to add things to this new language in another language, all within about 4 weeks, so I guess it's understandable that it's going a bit slower than I would like, but that doesn't make it any less frustrating...
Posted: Tue Jun 13, 2006 7:45 am
by Jay
About the performance:
I've made some C-unions that are capable of doing two calculatings at once, if they are the same.
It's like this:
you have a 32bit-processeor. Because of that, you can EITHER make 1 calculation with 32bit or 1 with 16bit.
BUT you can split up the 32bit into 2*16bit and calculate 2 things at once.
With an 64bit cpu it's the same with 64bit and 32bit variables.
Since i don't have a 64bit cpu like athlon64 i've tested it with the 32bit version and i got a 40% speed increase! This is NOT the thoerethical speed, but the real, bacause i used 2 additional counter variables that were normal variables.
I am not for calculating things with 16bit, but maybe we can think about RF2 being blazing speed on 64bit cpus.
maybe:
vector3d<Int64> v1,v2 //each 2 vector3d<int>
v1+=v2; //Is 40% faster as v11+=v21; v12+=v22; on a 64bit cpu
I am sortry i cannot write more, i have to go to school now!!!
Posted: Tue Jun 13, 2006 7:56 am
by QuestOfDreams
There are much better ways (supported in hardware) to do several calculations at once: SIMD (Single Instruction Multiple Data)
There's MMX for integer operations and SSE/SSE2 for floating point operations. Almost all modern computers should support it...
Posted: Tue Jun 13, 2006 11:29 am
by Jay
But then you would have to know the exact assembler which i don't. Also i thought the compiler would do this for me?
Posted: Tue Jun 13, 2006 1:11 pm
by QuestOfDreams
But then you would have to know the exact assembler which i don't.
Of course you would have to know assembler - that's the fun/ugly part of optimizing code
Also i thought the compiler would do this for me?
Yes, the compiler can optimize your code, but only in standard assembler code. MMX and SSE are special instructions/registers that are not available on all computers. If you want to use this special features you must first check if your cpu supports them, therefore a compiler just can't use them for standard code generation. Also it's rather easy for humans to see where parallel processing of data is possible and useful whereas the compiler would certainly have problems to detect such code areas.
Also, your code is problematic since there's no protection against overflow... the result of the low word addition might influence the high word. In the MMX instruction set for example there exist special instructions that only operate on a part of the register (e.g. only on the low word)
Posted: Tue Jun 13, 2006 1:23 pm
by Jay
QuestOfDreams wrote:
Also, your code is problematic since there's no protection against overflow... the result of the low word addition might influence the high word. In the MMX instruction set for example there exist special instructions that only operate on a part of the register (e.g. only on the low word)
ok that's a point.
Posted: Fri Jun 23, 2006 6:43 am
by moogal
Wow. Tnat's all I can say... wow. Some of you may have seen me around before, but probably not. This is my first post in the new forum. I've been elsewhere following BV, Irrlicht, Sylphis, and 3Impact for the last few months.
I had no idea anyone was trying to rewrite RF around Irrlicht. I promise I won't tell anyone
Anyone ever hear of 3DCakewalk?
I'm an art guy. I don't want to code, I want to model, texture and light environments. I want to drag sliders, input numbers and play with presets. Of all the game creation suites I've watched, RF is the only one I ever thought I could likely learn. Sadly, I preordered Quikly Game Studio instead from the TGC forums (no affiliation though) and lost $40 (Scam!). I should've dl'd RF when I still had broadband...
AndyCR, good luck with this. It seems like code just falls out of your head from what I gather. I've been thinking I should learn python since Poser (hey, it's got a great renderer!) and Panda 3D also use it. Now I think it's unavoidable.
I'll be around here while perpetually waiting for the next zBrush update...