Wednesday 2 October 2013

Wednesday None Woes

How Short A Season

I remember it was almost only yesterday I blogged of Wednesday woes. This Wednesday was better, with a successful meeting. I also admit to enjoying the drive into Wrexham South, as I rarely get a chance to drive in what seems a perpetual crunch and it was nice to slice through the Welsh terrain with music playing in the background. 

It is nonetheless very exhausting to drive, and once I had eaten and fed, the imperative was there to continue coding but the physical energy was not. Having started this particular at 5AM I think the smart money is to retire early and start a new day Thursday,

Signing Off

As a result, absolutely no new secrets will be revealed about Reloaded today, and the only purpose of this blog is to fill this most critical day in my effort to fill as many days in 2013 with blog posts as possible. The meeting did highlight MANY ideas and future plans, all of which unwise to repeat in such a casual blog, but rest assured our plans for the technology are nothing short of galactic!

For the hear and now, Lee rests. On the morrow, I jump ion earnest into saving and loading the entire scene, further refining editor control and adding the all important weapons, AI and physics to the present simulation. My path is clear, and my goal certain. Get your hard drives ready for a beta binary come October's end.

15 comments:

  1. Whats the binary of beta binary mean in respect to the beta version? I've heard of alpha and beta testing but not beta binary.

    ReplyDelete
    Replies
    1. By a binary, he just means a FPSCR Beta that is executable, not the source code.

      Delete
  2. lol :D

    Lee, with regards to picking a point on a terrain with the mouse: Is there a way, in DBPro, to multiply a matrix4 by a vector4 (not a vector4 by a matrix4, as AFAIK there's a difference)?

    ReplyDelete
  3. Lee sounds like he was all talked out. I wonder how he will "jump ion earnest"? Hopefully the rest will do him good. I too need a good sleep after listening to Lee waffle on all day long! :-)

    Our monthly meetings are a great motivation to us all and we get to stand back and look at where we are, what's important and ask each other about issues we may have been struggling with.

    We have lots to do this month and you'll start to see a lot of Reloaded activity as the autumn winds blow and a new game creator evolves and appears ready for it's first baby steps in your hands!

    ReplyDelete
  4. Your meeting seems to have added some vigor and excitement to the teams vision for Reloaded.

    I hope we can all share that soon and am pleased to hear of the progress to come next with the additions to getting those things to the Editor and scene. Look forward to that.

    Hard disks are ready for a Galactic journey and experience at the speed of light.

    :-)

    ReplyDelete
  5. All sounds good to me,nice one.

    ReplyDelete
  6. I have a question I would like to ask now though I am not sure if its appropriate at this time as I know its early days yet and Reloaded has a long way to go yet.

    Can I ask if Reloaded will have provision with relevance particularly for actual in game level display the ability/option to accommodate the users display Aspect Ratio so the rendering of the game image is not distorted?

    I have noticed some obvious variation in this during development to date. In for example an earlier video showing dynamic shadows and the weapon with environmental mapping on the scope of the weapon as a perfect example the aspect Ratio was correct and thus looked excellent.

    Since then I have noticed more recent screen shots to date where the same weapon is shown where the scope is not round but distorted to the oval and the scene distorted obviously.

    Ideally Reloaded should have the ability to display game levels as they should be and as intended so that game scene and content are not distorted. Game levels and game elements are created presumably at some kind of real world scale generally speaking and purposefully so for a reason. They look normal and not abnormal as we understand things to be visually. e.g. simply put it looks poor, unprofessional and unrealistic when rooms, characters, doors and so on all look as if they belong in a world of dwarves or are overweight being extended unnaturally in the horizontal plane.

    Enough said on that.

    :-)

    ReplyDelete
  7. Lee: Here's that code you requested for picking a position on the terrain with the cursor. It took me literally all day to figure it out, but I wanted to know how myself, so I took the time to do it properly. It requires some way to raycast (I used to Sparky's DLL for my tests). Finally, here it is:



    sync on
    sync rate 0
    autocam off
    set display mode desktop width(),desktop height(),32,1
    sync

    global camrange=1000
    global screenwidth#=0.0 //in vars to force floating maths
    global screenheight#=0.0

    screenwidth#=desktop width()
    screenheight#=desktop height()

    load object "test.x",1
    make object sphere 2,0.4 //hit indicator

    color object 2,rgb(255,0,0) //make the indicator bright red

    //position object 1,0,0,80

    sc_setupobject 1,0,0

    move camera -80
    move camera right 50

    set camera range 1,1000

    global m4_view=1
    global m4_projection=2
    global m4_viewproj=3
    global v4_near=4
    global v4_far=5
    global v3_far=6

    blank=make matrix4(m4_view)
    blank=make matrix4(m4_projection)
    blank=make matrix4(m4_viewproj)
    blank=make vector4(v4_near)
    blank=make vector4(v4_far)
    blank=make vector3(v3_far)

    projection matrix4 m4_projection

    do
    set cursor 0,0
    print ""
    print ""
    print "HOLD RMB TO ROTATE CAMERA AND USE ARROW KEYS TO MOVE CAMERA"

    view matrix4 m4_view //only necessary to update this matrix when the camera changes position/rotation
    set vector4 v4_near,((mousex()/screenwidth#)*2)-1,-(((mousey()/screenheight#)*2)-1),0,1
    set vector4 v4_far,((mousex()/screenwidth#)*2)-1,-(((mousey()/screenheight#)*2)-1),1,1
    multiply matrix4 m4_viewproj,m4_view,m4_projection
    blank=inverse matrix4(m4_viewproj,m4_viewproj)
    transform vector4 v4_near,v4_near,m4_viewproj
    transform vector4 v4_far,v4_far,m4_viewproj
    set vector3 v3_far,x vector4(v4_far),y vector4(v4_far),z vector4(v4_far) //normalisation would be affected if it were a vec4
    normalize vector3 v3_far,v3_far
    multiply vector3 v3_far,camrange

    hit=sc_raycast(1,x vector4(v4_near),y vector4(v4_near),z vector4(v4_near),x vector3(v3_far),y vector3(v3_far),z vector3(v3_far),0)
    if hit=1 then position object 2,sc_getstaticcollisionx(),sc_getstaticcollisiony(),sc_getstaticcollisionz()

    gosub _cameracontrol

    sync
    loop

    _cameracontrol:
    if mouseclick()=2
    hide mouse
    movex#=mousemovex()/10.0
    movey#=mousemovey()/10.0
    yrotate camera camera angle y()+(movex#+oldmovex#)/2.0
    xrotate camera camera angle x()+(movey#+oldmovey#)/2.0
    position mouse screen width()/2,screen height()/2
    oldmovex#=movex#
    oldmovey#=movey#
    if camera angle x()>90 then rotate camera 90,camera angle y(),camera angle z()
    if camera angle x()<-90 then rotate camera -90,camera angle y(),camera angle z()
    if camera angle y()>360 then rotate camera camera angle x(),0,camera angle z()
    if camera angle y()<0 then rotate camera camera angle x(),360,camera angle z()
    else
    show mouse
    endif
    if upkey()=1 then move camera 1
    if downkey()=1 then move camera -1
    if leftkey()=1 then move camera left 1
    if rightkey()=1 then move camera right 1
    return



    The important part is this:



    view matrix4 m4_view //only necessary to update this matrix when the camera changes position/rotation
    set vector4 v4_near,((mousex()/screenwidth#)*2)-1,-(((mousey()/screenheight#)*2)-1),0,1
    set vector4 v4_far,((mousex()/screenwidth#)*2)-1,-(((mousey()/screenheight#)*2)-1),1,1
    multiply matrix4 m4_viewproj,m4_view,m4_projection
    blank=inverse matrix4(m4_viewproj,m4_viewproj)
    transform vector4 v4_near,v4_near,m4_viewproj
    transform vector4 v4_far,v4_far,m4_viewproj
    set vector3 v3_far,x vector4(v4_far),y vector4(v4_far),z vector4(v4_far) //normalisation would be affected if it were a vec4
    normalize vector3 v3_far,v3_far
    multiply vector3 v3_far,camrange



    I hope that helps.

    ReplyDelete
  8. For easier-to-read code, have a look at the forum post: http://forum.thegamecreators.com/?m=forum_view&t=208077&b=1&p=0

    ReplyDelete
  9. hello
    This is my first time trying this so here we go ok i have two video cards my oldest one is on my pc which is 6600 nvidia yes you read right. But it works with fpsc my second is a lap top and it uses a 460 nvidia.which seems to run unreal ok.Why fpsc well its the easiest for me:) I have a question how will model packs work with reloaded if segs are no more most packs have segs with them and if there are no segs then wont we get an error when we try to load it ??????

    ReplyDelete
  10. I also have an Nvidia 7200 (or was it 7300...?), so pretty close to sam fisher's 6600.

    ReplyDelete
  11. I regret turning it into a 'who's got the oldest card' compo :) I'm really just interested in the expectation of what you think it ought to run on. I am thinking a card from 2/3 years ago.

    ReplyDelete
  12. Well we have no idea until we test it. We all think it should run on every card but trust me, we can't make an informed decision about how well it _should_ run until we know how well it _does_ run. It's silly but we all (well ok maybe just me) feel this way.

    ReplyDelete
  13. I think 2 to 3 years old is good. After 5 years they start to falter and as we aiming future we should go with what you say. It is a game maker. For game machines I believe. But whatever you feel is good

    ReplyDelete