736
Announcements / Re: Woohoo!
« on: 2011-Feb-04 »
Darmakwolf you're so lucky getting everything you need for iThings development like that!
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.
737
Off Topic / Re: What would be best to learn? C#, C++ or Objective C?
« on: 2011-Jan-31 »
Thanks for the advice. I start tonight. 
738
GLBasic - en / Re: Question: tween from rgb to rgb
« on: 2011-Jan-31 »
Slydog thanks very much for a look at that tween library of yours. Whole lot of useful stuff there.
739
Beta Tests / Re: Galactic Bird Beta
« on: 2011-Jan-31 »
Great first game, especially if you're new to programming. Keep it up!
Also, the music is Hybrid Song (Funky Stars) by the incredibly talented Trance/House DJ Axwell. This is the sort of thing he's up to nowadays: http://www.youtube.com/watch?v=4xgQk_xrTj0
Since the track is public domain you are free to distribute it. Would be the done thing to give him credit as Quazar of Sanxion of course.
See here: http://en.wikipedia.org/wiki/Axwell
Also, the music is Hybrid Song (Funky Stars) by the incredibly talented Trance/House DJ Axwell. This is the sort of thing he's up to nowadays: http://www.youtube.com/watch?v=4xgQk_xrTj0
Since the track is public domain you are free to distribute it. Would be the done thing to give him credit as Quazar of Sanxion of course.
See here: http://en.wikipedia.org/wiki/Axwell
740
Bug Reports / FINDPATH - least cost heuristic doesn't work
« on: 2011-Jan-31 »
When I use FINDPATH with heuristic 1.0 the result should be the path with least cost. I'm not sure what heuristic 1.0 is doing but finding the least cost path is definitely not it!
I've attached a little test proggy to demonstrate what I mean. The red path is heuristic 0.0 and the blue path is heuristic 1.0. Lower down the screen is shown the number of path steps that have to be taken and the cost of the path. As you will see, something odd is happening.
Please excuse the awfulness of the code. I wrote the routine a long time ago and just never thought to mention the issue.
I've attached a little test proggy to demonstrate what I mean. The red path is heuristic 0.0 and the blue path is heuristic 1.0. Lower down the screen is shown the number of path steps that have to be taken and the cost of the path. As you will see, something odd is happening.
Please excuse the awfulness of the code. I wrote the routine a long time ago and just never thought to mention the issue.
741
Off Topic / What would be best to learn? C#, C++ or Objective C?
« on: 2011-Jan-30 »
I've decided I simply can't put off learning a variation of the C language. I'm thinking I should learn C++ simply because its so widely used for computer game programming. My hesitation is that I already have many books on C# and Objective C that someone bought for me in order to try to encourage me to start learning them instead of C++.
The reason I want to learn is that for some simple but repetitive routines I would need to use in my GLBasic games it would be much faster to use things like IMPORT and INLINE to include C++ code. I'm not new to object-orientated programming because I used to program in Java some years ago so I'm guessing I shouldn't find it too hard to pick up.
C++ would be best, no? And if so, what would be a good start? What kind of development environment do you like to use? i.e. editor, compilers, interpreters? etc.
The reason I want to learn is that for some simple but repetitive routines I would need to use in my GLBasic games it would be much faster to use things like IMPORT and INLINE to include C++ code. I'm not new to object-orientated programming because I used to program in Java some years ago so I'm guessing I shouldn't find it too hard to pick up.
C++ would be best, no? And if so, what would be a good start? What kind of development environment do you like to use? i.e. editor, compilers, interpreters? etc.
742
GLBasic - en / Re: More speed for FINDPATH function?
« on: 2011-Jan-30 »
By the looks of that map a heuristic of 0.0 (shortest path) would be best. In fact, I'm not sure that setting a heuristic above 0 is a good idea. Its meant to find the path of least cost but in my testing heuristics of 0.5 and above actually result in typically longer paths that cost more than heuristics of 0.0! I really should report it as a bug and create some example code. Anyway, you don't need to worry about that because it looks like the walkable tiles in your game will all be traversed with the same cost/speed.
Incidentally, about reducing the map size being quicker, well sure it will! Having a much smaller search area will massively increase the speed of an A* pathfinding algorithm (which is what PATHFIND() is).
Check out this video here: http://www.youtube.com/watch?v=FNRfSQDF7TA
You can see from the above that A*will end up searching a very wide area in order to find its goal unless the goal is close by. Line of sight also matters, depending on the type of heuristic you're using. Regardless, a smaller search area be quicker. Having few or no large open spaces within the map to be searched will also be quicker since that naturally restricts the search area too.
For real speed on a large map you definitely need Hierarchical A* Pathfinding. That's the proper name for what I was trying to explain as making your map "break into chunks". Its also more complicated though and works best if there are choke points of 1 tile, like corridors or doors, that can naturally divide up the map into discrete areas. The reason to use it if possible is its so fast that you could conceivably use it on a very large map with many AI agents doing pathfinding searches without being too CPU expensive. So long as you stick to 4-way directions its possible to use PATHFIND() with it too without having to create your own A* routine.
Incidentally, about reducing the map size being quicker, well sure it will! Having a much smaller search area will massively increase the speed of an A* pathfinding algorithm (which is what PATHFIND() is).
Check out this video here: http://www.youtube.com/watch?v=FNRfSQDF7TA
You can see from the above that A*will end up searching a very wide area in order to find its goal unless the goal is close by. Line of sight also matters, depending on the type of heuristic you're using. Regardless, a smaller search area be quicker. Having few or no large open spaces within the map to be searched will also be quicker since that naturally restricts the search area too.
For real speed on a large map you definitely need Hierarchical A* Pathfinding. That's the proper name for what I was trying to explain as making your map "break into chunks". Its also more complicated though and works best if there are choke points of 1 tile, like corridors or doors, that can naturally divide up the map into discrete areas. The reason to use it if possible is its so fast that you could conceivably use it on a very large map with many AI agents doing pathfinding searches without being too CPU expensive. So long as you stick to 4-way directions its possible to use PATHFIND() with it too without having to create your own A* routine.
743
GLBasic - en / Re: More speed for FINDPATH function?
« on: 2011-Jan-29 »
A piece of the map? Hmm. I wouldn't know how the actual PATHFIND() routine itself is coded but A* pathfinding in general can be sped up a lot if you break up your map into large chunks. Is that what you mean?
If you break into chunks, on any particular search you don't have to calculate the path through the entire map but just through the chunks themselves to see how to get to the one you want to go and from within the chunk you are in at the time of the search. If you get my meaning then you'll see that instead of running PATHFIND() once its necessary to run it twice but its much quicker on both occasions.
Please note that doing the above results in a search that is no longer admissible, i.e. it (most likely) won't find the fastest possible route. However, it will get very close to fastest route possible and will look natural enough. That should be adequate, especially if you need to keep your pathfinding quick.
If you wanted to have a go writing your own pathfinding routine I found an article by a guy claiming his version of A* pathfinding is 300 to 1500 times quicker than the conventional method: http://www.codeguru.com/csharp/csharp/cs_misc/designtechniques/article.php/c12527
I haven't tested his method for myself but a claim like that did interest me. I mean to give it a try at some point.
If you break into chunks, on any particular search you don't have to calculate the path through the entire map but just through the chunks themselves to see how to get to the one you want to go and from within the chunk you are in at the time of the search. If you get my meaning then you'll see that instead of running PATHFIND() once its necessary to run it twice but its much quicker on both occasions.
Please note that doing the above results in a search that is no longer admissible, i.e. it (most likely) won't find the fastest possible route. However, it will get very close to fastest route possible and will look natural enough. That should be adequate, especially if you need to keep your pathfinding quick.
If you wanted to have a go writing your own pathfinding routine I found an article by a guy claiming his version of A* pathfinding is 300 to 1500 times quicker than the conventional method: http://www.codeguru.com/csharp/csharp/cs_misc/designtechniques/article.php/c12527
I haven't tested his method for myself but a claim like that did interest me. I mean to give it a try at some point.
744
Code Snippets / Re: Change a sprite's hue, saturation and brightness
« on: 2011-Jan-29 »Cool thing
I must admit, I've never used MEM2SPRITE until now. Is it fast enough to be used for ingame sprite manipulation? Or should it be used with care?
IMO not a good idea to use it on the fly each frame, i.e. in-game. Even if you increased speed by greatly reducing the number of colours you have to work with by keeping them in a pre-calculated list and skipped alpha channel with 0 value it would still be slow even on relatively fast PCs. Its quick, but not that quick.
The kind of practical thing you can do is re-colour a whole set of sprites on a sprite sheet for use later. In this way its not unlike loading a whole new set of sprites (and about as quick). When actually in use they'd work just the same as the original sprites. For example, in a real-time strategy game you could allow the user to make personalised colour changes to their standard set of units before a game starts. Same with a fighting game like the classic 2D versions of Street Fighter games. Another example would be a character creation screen for an RPG. You could allow the user to customise the colour scheme for their player characters in addition to all the other settings.
745
Code Snippets / Re: Change a sprite's hue, saturation and brightness
« on: 2011-Jan-29 »
Ok, so clear explanation of ShiftColorValue function
newcolor% = ShiftColorValue ( oldcolor%, brightness%, saturation%, hue% )
The variable newcolor is given a value in RGBA calculated from oldcolor according to settings brightness, saturation and hue.
brightness can be given values from 0 to 200. 0 is totally black. 200 is totally white. 100 is normal brightness.
saturation can be given values from 0 to 200. 0 is totally colourless - black & white. 200 is maximum saturation. 100 is normal saturation. Be careful using values above 100. While this can work well much of the time it can produce odd results in some sprites when brightness is over 100.
hue can be given values from 0 to 359. 0 is no change whatsoever. 180 results in the complete opposite colour.
newcolor% = ShiftColorValue ( oldcolor%, brightness%, saturation%, hue% )
The variable newcolor is given a value in RGBA calculated from oldcolor according to settings brightness, saturation and hue.
brightness can be given values from 0 to 200. 0 is totally black. 200 is totally white. 100 is normal brightness.
saturation can be given values from 0 to 200. 0 is totally colourless - black & white. 200 is maximum saturation. 100 is normal saturation. Be careful using values above 100. While this can work well much of the time it can produce odd results in some sprites when brightness is over 100.
hue can be given values from 0 to 359. 0 is no change whatsoever. 180 results in the complete opposite colour.
Code: GLBasic [Select]
FUNCTION ShiftColorValue: color, bri, sat, hue
// color is the original color to change according to the following values:-
// bri = brightness. Can be 0 to 100 to 200. 0 = total darkness. 100 = normal light. over 100 you'll get a bleached look - "over" brightness
// sat = saturation. Can be 0 to 100 to 200. 0 = black & white. 100 = normal saturation. over 100 is "over" saturation. More colourful.
// hue = hue shift. Can be 0 to 359. 0 is no change.
LOCAL hu, cmax%, cmin%, diff, r%, g%, b%, a%, tmin%, tdiff%
a = BAND(ASR(color,24),0xff)
IF a = 0
RETURN color
ELSE
r = BAND(color,0xff)
g = BAND(ASR(color,8),0xff)
b = BAND(ASR(color,16),0xff)
cmax = MAX(b,MAX(r,g))
cmin = MIN(b,MIN(r,g))
diff = cmax-cmin
// hue calculations - hu = hue of color%
IF hue <> 0
IF r > g
IF g > b // 7 Between red and yellow
hu = ((g-b)/diff)*60
ELSEIF b > g
IF b = r
hu = 300 // Pure Magnenta
ELSE
hu = 300 + ((r-b)/diff)*60 // 12 Between Magnenta and Red
ENDIF
ELSE // g = b
hu = 0 // 1 Pure Red
ENDIF
ELSEIF g > b
IF b > r // 9 Between green and cyan
hu = 120 + ((b-r)/diff)*60
ELSEIF r > b // 8 Between yellow and green
IF r = g // Pure Yellow
hu = 60
ELSE
hu = 60 + ((g-r)/diff)*60 // 8 Between yellow and green
ENDIF
ELSE // b = r
hu = 120 // 3 Pure green
ENDIF
ELSE // b > r
IF r > g // 11 Between blue and magnenta
hu = 240 + ((r-g)/diff)*60
ELSEIF g > r
IF g = b // Pure Cyan
hu = 180
ELSE
hu = 180 + ((b-g)/diff)*60 // 10 Between cyan and blue
ENDIF
ELSE // r = g
hu = hu = 240 // 5 Pure blue
ENDIF
ENDIF
// Adjust hue
hue = hue + hu
IF hue >= 360 THEN DEC hue, 360
IF hue > 0 AND hue < 60 // Between red and yellow
r = cmax
b = cmin
g = cmin+(hue*(diff/60))
ELSEIF hue > 60 AND hue < 120 // Between Yellow and green
g = cmax
b = cmin
r = cmax-((hue-60)*(diff/60))
ELSEIF hue > 120 AND hue < 180 // Between green and cyan
g = cmax
r = cmin
b = cmin+((hue-120)*(diff/60))
ELSEIF hue > 180 AND hue < 240 // Between cyan and blue
b = cmax
r = cmin
g = cmax-((hue-180)*(diff/60))
ELSEIF hue > 240 AND hue < 300 // Betweeen blue and magnenta
b = cmax
g = cmin
r = cmin+((hue-240)*(diff/60))
ELSEIF hue > 300 // Between mangenta and red
r = cmax
g = cmin
b = cmax-((hue-300)*(diff/60))
ELSEIF hue = 0 // Pure Red
r = cmax
g = cmin
b = cmin
ELSEIF hue = 60 // Pure Yellow
r = cmax
g = cmax
b = cmin
ELSEIF hue = 120 // Pure Green
r = cmin
g = cmax
b = cmin
ELSEIF hue = 180 // Pure Cyan
r = cmin
g = cmax
b = cmax
ELSEIF hue = 240 // Pure Blue
r = cmin
g = cmin
b = cmax
ELSEIF hue = 300 // Pure magnenta
r = cmax
g = cmin
b = cmax
ENDIF
ENDIF
// Adjust saturation
IF sat <> 100
sat = 100-sat
IF r <> cmax
tmin = r
tdiff = cmax - tmin
r = tmin + tdiff*(sat/100)
ENDIF
IF g <> cmax
tmin = g
tdiff = cmax - tmin
g = tmin + tdiff*(sat/100)
ENDIF
IF b <> cmax
tmin = b
tdiff = cmax - tmin
b = tmin + tdiff*(sat/100)
ENDIF
ENDIF
// Adjust brightness
IF bri <> 100
IF bri = 0
r = 0
g = 0
b = 0
ELSE
DEC r, (100-bri)*2.55
DEC g, (100-bri)*2.55
DEC b, (100-bri)*2.55
ENDIF
ENDIF
IF r < 0 THEN r = 0
IF r > 255 THEN r = 255
IF g < 0 THEN g = 0
IF g > 255 THEN g = 255
IF b < 0 THEN b = 0
IF b > 255 THEN b = 255
RETURN BOR(RGB(r,g,b), ASL(a, 24))
ENDIF
ENDFUNCTION
// color is the original color to change according to the following values:-
// bri = brightness. Can be 0 to 100 to 200. 0 = total darkness. 100 = normal light. over 100 you'll get a bleached look - "over" brightness
// sat = saturation. Can be 0 to 100 to 200. 0 = black & white. 100 = normal saturation. over 100 is "over" saturation. More colourful.
// hue = hue shift. Can be 0 to 359. 0 is no change.
LOCAL hu, cmax%, cmin%, diff, r%, g%, b%, a%, tmin%, tdiff%
a = BAND(ASR(color,24),0xff)
IF a = 0
RETURN color
ELSE
r = BAND(color,0xff)
g = BAND(ASR(color,8),0xff)
b = BAND(ASR(color,16),0xff)
cmax = MAX(b,MAX(r,g))
cmin = MIN(b,MIN(r,g))
diff = cmax-cmin
// hue calculations - hu = hue of color%
IF hue <> 0
IF r > g
IF g > b // 7 Between red and yellow
hu = ((g-b)/diff)*60
ELSEIF b > g
IF b = r
hu = 300 // Pure Magnenta
ELSE
hu = 300 + ((r-b)/diff)*60 // 12 Between Magnenta and Red
ENDIF
ELSE // g = b
hu = 0 // 1 Pure Red
ENDIF
ELSEIF g > b
IF b > r // 9 Between green and cyan
hu = 120 + ((b-r)/diff)*60
ELSEIF r > b // 8 Between yellow and green
IF r = g // Pure Yellow
hu = 60
ELSE
hu = 60 + ((g-r)/diff)*60 // 8 Between yellow and green
ENDIF
ELSE // b = r
hu = 120 // 3 Pure green
ENDIF
ELSE // b > r
IF r > g // 11 Between blue and magnenta
hu = 240 + ((r-g)/diff)*60
ELSEIF g > r
IF g = b // Pure Cyan
hu = 180
ELSE
hu = 180 + ((b-g)/diff)*60 // 10 Between cyan and blue
ENDIF
ELSE // r = g
hu = hu = 240 // 5 Pure blue
ENDIF
ENDIF
// Adjust hue
hue = hue + hu
IF hue >= 360 THEN DEC hue, 360
IF hue > 0 AND hue < 60 // Between red and yellow
r = cmax
b = cmin
g = cmin+(hue*(diff/60))
ELSEIF hue > 60 AND hue < 120 // Between Yellow and green
g = cmax
b = cmin
r = cmax-((hue-60)*(diff/60))
ELSEIF hue > 120 AND hue < 180 // Between green and cyan
g = cmax
r = cmin
b = cmin+((hue-120)*(diff/60))
ELSEIF hue > 180 AND hue < 240 // Between cyan and blue
b = cmax
r = cmin
g = cmax-((hue-180)*(diff/60))
ELSEIF hue > 240 AND hue < 300 // Betweeen blue and magnenta
b = cmax
g = cmin
r = cmin+((hue-240)*(diff/60))
ELSEIF hue > 300 // Between mangenta and red
r = cmax
g = cmin
b = cmax-((hue-300)*(diff/60))
ELSEIF hue = 0 // Pure Red
r = cmax
g = cmin
b = cmin
ELSEIF hue = 60 // Pure Yellow
r = cmax
g = cmax
b = cmin
ELSEIF hue = 120 // Pure Green
r = cmin
g = cmax
b = cmin
ELSEIF hue = 180 // Pure Cyan
r = cmin
g = cmax
b = cmax
ELSEIF hue = 240 // Pure Blue
r = cmin
g = cmin
b = cmax
ELSEIF hue = 300 // Pure magnenta
r = cmax
g = cmin
b = cmax
ENDIF
ENDIF
// Adjust saturation
IF sat <> 100
sat = 100-sat
IF r <> cmax
tmin = r
tdiff = cmax - tmin
r = tmin + tdiff*(sat/100)
ENDIF
IF g <> cmax
tmin = g
tdiff = cmax - tmin
g = tmin + tdiff*(sat/100)
ENDIF
IF b <> cmax
tmin = b
tdiff = cmax - tmin
b = tmin + tdiff*(sat/100)
ENDIF
ENDIF
// Adjust brightness
IF bri <> 100
IF bri = 0
r = 0
g = 0
b = 0
ELSE
DEC r, (100-bri)*2.55
DEC g, (100-bri)*2.55
DEC b, (100-bri)*2.55
ENDIF
ENDIF
IF r < 0 THEN r = 0
IF r > 255 THEN r = 255
IF g < 0 THEN g = 0
IF g > 255 THEN g = 255
IF b < 0 THEN b = 0
IF b > 255 THEN b = 255
RETURN BOR(RGB(r,g,b), ASL(a, 24))
ENDIF
ENDFUNCTION
746
Bug Reports / Re: Hacked Highscores
« on: 2011-Jan-28 »
OMG! Leginus thanks for drawing my attention to that. I forgot that our world is shaped by insane war monkeys who try to control everything. App submission with any encryption confirmed as a confusing headache in the US: http://discussions.apple.com/thread.jspa?threadID=1647892
However, I've been looking here: http://www.bis.doc.gov/encryption/default.htm and at the documents linked to it like this one: http://www.bis.doc.gov/encryption/decision_tree.pdf
It seems that there are exceptions. For instance by US export standards '"Cryptography" does not include "fixed" data compression or coding techniques.' and if the software uses encryption for authentication only then its OK with US export law, etc. Not sure if Apple would still require you to submit your app with approved encryption though.
I'm going to go ahead and assume that checksums used to authenticate stored data do not need registration.
However, I've been looking here: http://www.bis.doc.gov/encryption/default.htm and at the documents linked to it like this one: http://www.bis.doc.gov/encryption/decision_tree.pdf
It seems that there are exceptions. For instance by US export standards '"Cryptography" does not include "fixed" data compression or coding techniques.' and if the software uses encryption for authentication only then its OK with US export law, etc. Not sure if Apple would still require you to submit your app with approved encryption though.
I'm going to go ahead and assume that checksums used to authenticate stored data do not need registration.
747
Bug Reports / Re: Hacked Highscores
« on: 2011-Jan-28 »
Yep. Don't forget INI files too! e.g the INI file to PowFish looks a little like this:-
[Quality]
FPS=d808b43bedc1035ff3419cc9c316b9d3f3419cc9c316b9d3
Detail=9d2be24871f6ea23e0baceb79ecffcf08ea0c730854802d6
Size=395a2709c03434543338acb4744c399a39272705932c42a4
[Sound]
Music_Volume=cb48e692c4ec50709aebc11e2c7e8be69aebc11e2c7e8be69aebc11e2c7e8be6
Sound_Volume=90a8dd135b93b307cdfdb1f1c0304a4acdfdb1f1c0304a4acdfdb1f1c0304a4a
Speech_Volume=ebaecde55c40d58af7c9855b36bee8edf7c9855b36bee8edf7c9855b36bee8ed
[Achievements]
ACHIEVE0=48f345ce3295e81e34eb89930e46238e85ce9c424fc736f3
ACHIEVE1=d1fccefd9f0c3ca9bb3ae8cf6211c6ebfb27ee1cc7bb6113
ACHIEVE2=e4d0ecd4944c98e21758d93e1193367c5e84be24d685e8b5
[Checksum]
Encrypts=17580fd65dc5e981f3419cc9c316b9d3f3419cc9c316b9d3f3419cc9c316b9d3f3419cc9c316b9d3
etc.
If the decoded data fails a checksum check then its all reset to default (very frustrating if you're trying to cheat).
[Quality]
FPS=d808b43bedc1035ff3419cc9c316b9d3f3419cc9c316b9d3
Detail=9d2be24871f6ea23e0baceb79ecffcf08ea0c730854802d6
Size=395a2709c03434543338acb4744c399a39272705932c42a4
[Sound]
Music_Volume=cb48e692c4ec50709aebc11e2c7e8be69aebc11e2c7e8be69aebc11e2c7e8be6
Sound_Volume=90a8dd135b93b307cdfdb1f1c0304a4acdfdb1f1c0304a4acdfdb1f1c0304a4a
Speech_Volume=ebaecde55c40d58af7c9855b36bee8edf7c9855b36bee8edf7c9855b36bee8ed
[Achievements]
ACHIEVE0=48f345ce3295e81e34eb89930e46238e85ce9c424fc736f3
ACHIEVE1=d1fccefd9f0c3ca9bb3ae8cf6211c6ebfb27ee1cc7bb6113
ACHIEVE2=e4d0ecd4944c98e21758d93e1193367c5e84be24d685e8b5
[Checksum]
Encrypts=17580fd65dc5e981f3419cc9c316b9d3f3419cc9c316b9d3f3419cc9c316b9d3f3419cc9c316b9d3
etc.
If the decoded data fails a checksum check then its all reset to default (very frustrating if you're trying to cheat).
748
Code Snippets / Re: xml parser
« on: 2011-Jan-28 »
Oh! Keep debugging. 
This is rather awesome. To be able to parse xml in GLBasic would open up some interesting possibilities.
This is rather awesome. To be able to parse xml in GLBasic would open up some interesting possibilities.
749
GLBasic - en / Re: Polyvector question
« on: 2011-Jan-28 »
Hi Helmos
I think this thread is the one you may have been looking for: http://www.glbasic.com/forum/index.php?topic=2543
I came across the same issue when doing an experiment to create a pseudo-3D floor like Diablo 2. I created a grid of tiles, drew them using some old-school perspective math and then slapped myself when I saw all of the tiles were slightly skewed! I decided 3D was the obvious choice. No need to reinvent the wheel.
Problem was I was so shy of looking at 3D functions at that time that I gave up! 
Perhaps I'll revive the project at some point. I have recently thought about what it would take to do a LAN rehash of the the classic SNES-style "Mode 7" Mario Kart battles. That was so much fun back in the day and yet so simple to pick up.
Yeh! For nostalgia purposes I still play some of my old PS1 games on an emulator occasionally. The lack of perspective correction makes classics like Soul Reaver and Tomb Raider look really odd nowadays.
I think this thread is the one you may have been looking for: http://www.glbasic.com/forum/index.php?topic=2543
I came across the same issue when doing an experiment to create a pseudo-3D floor like Diablo 2. I created a grid of tiles, drew them using some old-school perspective math and then slapped myself when I saw all of the tiles were slightly skewed! I decided 3D was the obvious choice. No need to reinvent the wheel.
Problem was I was so shy of looking at 3D functions at that time that I gave up! Perhaps I'll revive the project at some point. I have recently thought about what it would take to do a LAN rehash of the the classic SNES-style "Mode 7" Mario Kart battles. That was so much fun back in the day and yet so simple to pick up.
Yes, what you want is "perspecitve correction", and you don't get it with real 2D. Search the forums, there was a thread about exaclty the same topic years ago.
BTW: That was the problem with many PSone games.
Yeh! For nostalgia purposes I still play some of my old PS1 games on an emulator occasionally. The lack of perspective correction makes classics like Soul Reaver and Tomb Raider look really odd nowadays.
750
Code Snippets / Change a sprite's hue, saturation and brightness
« on: 2011-Jan-28 »
UPDATE!
The function ShiftColorValue has been improved. The calculations have been optimised and it only does the minimum work needed to get its result. You can now also saturate and brighten the original sprite more than the original values. All round a better approach. The new routine has been attached to this post.
See my second post below on this thread for an explanation of the ShiftColorValue function
Back to OP:-
---------------------------
Wrote a routine to see how I could use SPRITE2MEM and MEM2SPRITE to create new sprites with different colour schemes. This sort of thing was seen a lot in the 16-bit era. Example screenshot:-
In this demo you can adjust the hue (rainbow bar), the brightness (dark to light bar) and saturation (gray to red bar) of Sagat's flesh, bandages, belt and shorts. Click 'Change' to have a look at the new sprite you've created with your settings and 'Default' to return to default
Just compile HueShiftExample.gbap to have a look.
The function ShiftColorValue has been improved. The calculations have been optimised and it only does the minimum work needed to get its result. You can now also saturate and brighten the original sprite more than the original values. All round a better approach. The new routine has been attached to this post.
See my second post below on this thread for an explanation of the ShiftColorValue function
Back to OP:-
---------------------------
Wrote a routine to see how I could use SPRITE2MEM and MEM2SPRITE to create new sprites with different colour schemes. This sort of thing was seen a lot in the 16-bit era. Example screenshot:-
In this demo you can adjust the hue (rainbow bar), the brightness (dark to light bar) and saturation (gray to red bar) of Sagat's flesh, bandages, belt and shorts. Click 'Change' to have a look at the new sprite you've created with your settings and 'Default' to return to default
Just compile HueShiftExample.gbap to have a look.