Long Source Codes

BlitzPlus Forums/BlitzPlus Beginners Area/Long Source Codes

Sauer

(Posted 2008) [#1]

I tend to write extremely long and inefficient source codes. Will this have any effect on the final product, or will it simply slow compiling.

I can deal with slow compiling, but if this would effect my final product I'm going to have to rethink my code structure.

Thanks in advance.

tonyg

(Posted 2008) [#2]

Depends on how well your final product matches the spec you have. If it does what it it suppose to at an acceptable speed then it's fine. If it doesn't then fix it and/or optimise it. If you want to reuse it then review what you have done.

Sauer

(Posted 2008) [#3]

Ok so I'm looking at a trial and error problem here?

If there is a problem, what will it cause; slow load times, slow overall execution, something else, or all of the above?

Dreamora

(Posted 2008) [#4]

No you aren't looking for a trial an error problem.
If it does not work you most likely have to rewrite whole parts in a clean way instead of hacking stuff together most likely.

As well if you have really long source code you might run into the max source size limitation of blitz

Zethrax

(Posted 2008) [#5]

It depends on what you mean by 'inefficient'. Badly written code will probably slow down the runtime execution of your program, but without seeing your code, it's impossible to say if it will or won't be an issue. Even if it does slow down runtime execution, will it do so to a degree that anyone using your program will ever notice? Most modern programming techniques favor code which is less efficient than it could be, but is much easier to manage, for example.

Bear in mind that the Blitz languages do some optimizations which 'collapse' complex code involving constant values or results, down to a simpler form. The code 'a = 2 + 2' would be collapsed to 'a = 4'. The code 'If 2 = 2 Then a = b' would be collapsed to 'a = b' as the result of the If expression would always be true.

tonyg

(Posted 2008) [#6]

To trap speed issues then I would suggest looking into profiling.
Basically, you track how long a function or operation takes to complete and how often it is called.
Once collected (in a type object) you can write the data out at the end of the program.
You can then look into optimising functions which take a long time or those called often.

Sauer

(Posted 2008) [#7]

Well, here's what I'm dealing with.
Variable p determines which area you are in.
Every area has its own function, pic1(),pic2(),pic3().
The main loop looks something like this:

While cont=True
	If p=1 Then pic1()
	If p=2 Then pic2()
	If p=3 Then pic3()
	If p=4 Then pic4()
	If p=5 Then pic5()
	If p=6 Then pic6()
        Flip
        Cls
Wend

And within each level functions are the general functions that control the mouse, interface, game elements, etc.

I could probably compact the level info into a data block or array and then combine all the level functions into one, but is this really necessary? I'm progressing well and thoroughly understand my program as is, but if it affects the final product I want to change it.

Hopefully this clarifies a bit... if you need more info maybe the worklog page will be of use.

Zethrax

(Posted 2008) [#8]

In the example above 'While cont=True' could be shortened to 'While cont' as the True test is implicit. It may compile the same either way, though.

The Ifs would probably be faster if implemented as a select case statement. The speed difference may not be worth the trouble, though:-

eg.

Select p
    Case 1
        pic1()
    Case 2
        pic2()
    Case 3
        pic3()
    Case 4
        pic4()
    Case 5
        pic5()
    Case 6
        pic6()
End Select

And within each level functions are the general functions that control the mouse, interface, game elements, etc.

I gather you mean that you're calling the code for these functions from inside your level function and not that you're implementing the code inside each function? Duplicating common functionality isn't efficient.

The approach you're using may make it difficult to add to your program in future, and may result in a lot of redundant code. In the long term, you will probably want to take a more data driven approach.

For your first few games, your main priority should be in getting a finished and working product out the door, whether it is freeware or commercial. These first games will be a learning experience. Over time, you will learn what you need to know to code more efficiently.

tonyg

(Posted 2008) [#9]

If P is always between 1-6 then that piece of code is unlikely to be causing any performance problems. What each of the functions do might cause a problem which is why you need to profile them.

Sauer

(Posted 2008) [#10]

From what I've gathered, I think I'll be alright to continue as is.

I understand this question is difficult to answer without the full source, but even so I've received helpful answers.

Thanks to all replies.

D4NM4N

(Posted 2008) [#11]

The Ifs would probably be faster if implemented as a select case statement. The speed difference may not be worth the trouble, though:-

They are more efficient as they break out and ignore the rest once a condition has been met (ie. "ok, pic=2 so i can do that bit and jump straight to end select ignoring 3,4,5 and 6") this is much better especially within intensive loops.

Another thing that speeds stuff up is:
When using custom types, if you have LOADS of references to the same field in a function(for example):

function updatemonster(mymonster.monster)

   ;-------------------------------------------------------------
   ;in this function there are say.. 50 references to these: 
   mymonster\xpos 
   mymonster\ypos 
   ;-------------------------------------------------------------

end function

Access to these is slower than normal vars, so this can sometimes be better:

function updatemonster(mymonster.monster)
   ;create some temp. local storage
   px#=mymonster\xpos 
   py#=mymonster\ypos 
   ;------------------------------------------------------------------------
   ;now in this function there are 50 odd references to these instead: 
   px
   py
   ;------------------------------------------------------------------------
   ;then we need to perform an update the data table on exit. 
   mymonster\xpos =px
   mymonster\ypos =py
end function

Is faster and more efficient because it is only accessing the type fields twice, 1 read and 1 write instead of 50 times each.

However, if its just a few refs (eg 5 or less, this doesnt help much) the difference is fairly neglegable (and pointless) for just a few, but for many references i find this temporary replacement a faster option, especially in intensive looping.

!!!However, be careful if using a return somewhere in the function above, as any required changes to field data can be lost!!!