Re: [Ohrrpgce] SVN: jay/4388 Fixed heap corruption by putting bounds checking before the surface writ
> From: subvers...@hamsterrepublic.com > Sent: Friday, June 03, 2011 11:33 PM > > jay > 2011-06-03 21:33:12 -0700 (Fri, 03 Jun 2011) > 76 > Fixed heap corruption by putting bounds checking before the surface writing. > --- > U wip/rasterizer.cpp And I fixed the clipping too. :) ___ Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting http://www.doteasy.com ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: jay/4387 Ever fewer bugs! Still clipping issue and slight artifacts.
> From: Mike Caron > Sent: Friday, June 03, 2011 11:16 PM > > On 6/4/2011 0:14, subvers...@hamsterrepublic.com wrote: > > jay > > 2011-06-03 21:14:55 -0700 (Fri, 03 Jun 2011) > > 59 > > Ever fewer bugs! Still clipping issue and slight artifacts. > > --- > > U wip/rasterizer.cpp > > When I saw your comment, I initially read "light artifacts", which > immediately parsed as "artifacts in the lighting". > > This line of thinking, of course, made me wonder how long before we get > pixel shaders? Actually it'd be as simple as adding 1 line calling a shader program per pixel being rasterized. That'd be quite fun to experiment with! I'm going to first guarantee it all works, though. ___ Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting http://www.doteasy.com ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: jay/4388 Fixed heap corruption by putting bounds checking before the surface writ
jay 2011-06-03 21:33:12 -0700 (Fri, 03 Jun 2011) 76 Fixed heap corruption by putting bounds checking before the surface writing. --- U wip/rasterizer.cpp ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/4377 savemapstate_npcl() now stores NPC locations using a RELOAD format
> If you think that's scary, you don't want to hear about a project I'm > considering: creating a C variant more suitable for implementation of > VMs (based on llvm/clang with custom optimisation passes)... told you > you didn't want to hear :) That actually sounds really cool. If you don't mind me asking, are you trying to make a more functional variant of C (e.g., adding closures would really help) or just a more friendly procedural language (e.g., built-in regular expressions)? -->Seth ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: jay/4387 Ever fewer bugs! Still clipping issue and slight artifacts.
On 6/4/2011 0:14, subvers...@hamsterrepublic.com wrote: jay 2011-06-03 21:14:55 -0700 (Fri, 03 Jun 2011) 59 Ever fewer bugs! Still clipping issue and slight artifacts. --- U wip/rasterizer.cpp When I saw your comment, I initially read "light artifacts", which immediately parsed as "artifacts in the lighting". This line of thinking, of course, made me wonder how long before we get pixel shaders? -- - Mike Caron ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: jay/4387 Ever fewer bugs! Still clipping issue and slight artifacts.
jay 2011-06-03 21:14:55 -0700 (Fri, 03 Jun 2011) 59 Ever fewer bugs! Still clipping issue and slight artifacts. --- U wip/rasterizer.cpp ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/4386 Removed the npcsl() array, and replaced it with a .sl member on NPCInst
james 2011-06-03 20:06:49 -0700 (Fri, 03 Jun 2011) 72 Removed the npcsl() array, and replaced it with a .sl member on NPCInst --- U wip/game.bas U wip/gglobals.bi U wip/udts.bi U wip/yetmore.bas U wip/yetmore2.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/4385 Oops, *actually* use the correct NPC loading code (fixes xgo/ygo related
james 2011-06-03 17:24:31 -0700 (Fri, 03 Jun 2011) 93 Oops, *actually* use the correct NPC loading code (fixes xgo/ygo related tile misalignment) --- U wip/loading.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: jay/4384 Minor adjustment to fpInt.h, and implemented Mike's suggestion for slope
jay 2011-06-03 16:38:44 -0700 (Fri, 03 Jun 2011) 218 Minor adjustment to fpInt.h, and implemented Mike's suggestion for slope overflow problem. It works, but clipping and a few artifacts need to be fixed. (Not sure if it crashes if the triangle is partially off-surface). --- U wip/fpInt.h U wip/rasterizer.cpp ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: jay/4381 Getting it closer to actually working (doesn't crash anymore, but it isn
> From: Mike Caron
> Sent: Friday, June 03, 2011 3:14 PM
>
> On 03/06/2011 2:34 PM, Jay Tennant wrote:
> >> From: Ralph Versteegen
> >> Sent: Friday, June 03, 2011 11:47 AM
> >>
> >> On 3 June 2011 06:00, Jay Tennant wrote:
> From: subvers...@hamsterrepublic.com
> Sent: Thursday, June 02, 2011 12:45 PM
> To: ohrrpgce@lists.motherhamster.org
> Subject: [Ohrrpgce] SVN: jay/4381 Getting it closer to actually working
> (doesn't crash anymore, but it isn
>
> jay
> 2011-06-02 10:45:09 -0700 (Thu, 02 Jun 2011)
> 94
> Getting it closer to actually working (doesn't crash anymore, but it
> isn't drawing right yet).
> >>>
> >>> Oh, it's drawing *mostly* correct. That's encouraging! :)
> >>
> >> Sounds good! So do you have a test program? Actually, I'll add a
> >> function to allmodex.bas to draw transformed rects, and can stick a
> >> test of it in the 'secret_menu' in custom.
> >
> > I'm running a test program of it right now, but it's so disappointing: the
> > overflow problem. If I have a fixed point number divided by a very small
> > fraction (say 1/65536th) I get a terribly inaccurate number. I don't want
> > to switch to floating point, but I don't think I have much choice. Is there
> > a solution to this that I'm not getting?
> >
> > Where the issue arises: the rasterizer evaluates a surface to be drawn to
> > one line at a time. The first pass is simply to figure what range of pixels
> > on each line is to be evaluated. The second pass (after all line's pixel
> > ranges are figured) is to interpolate the edge values across the line for
> > each pixel. The error is occurring during the first pass, in figuring the
> > left-most and right-most boundary of a line of pixels to be rasterized.
> >
> > For each line, I take the slope of the edges of the triangle and find all
> > x-intercepts. The left-most intercept and the right-most intercept
> > (as long as they're within range of the triangle) are the boundaries of
> > the pixels.
> >
> > I realize they're some optimizations I could perform (like calculating the
> > edge slopes once), but the error occurs when an edge is almost completely
> > vertical. The fixed point integer can't represent +/- infinite, so an
> > overflow/underflow occurs in determining slope (dy / almost 0).
> >
> > I think the solution is using floating point math for this section. Can
> > you think of another solution? Other than that, the rasterizer's working
> > pretty nicely. I'll commit the code when I'm able to.
>
> Does you algorithm allow for swapping axes? Eg,
>
> if(dy > dx) {
> //swap values, and flip the result turn-ways
> }
>
> I don't know if this is possible in your case, however.
What a clever way around that! I think this will solve the problem! :D
When I'm free later, I'll use that method and commit the (hopefully
working) code.
___
Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting
http://www.doteasy.com
___
Ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/4383 Use the same code to save/load temporary NPC state as for save/load NPC
james 2011-06-03 16:00:41 -0700 (Fri, 03 Jun 2011) 157 Use the same code to save/load temporary NPC state as for save/load NPC state in RSAV (although this code was not, and still is not called by the RSAV code) --- U wip/loading.bas U wip/loading.bi U wip/savegame.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/4382 Don't save "hidden" property for NPC locations in RSAV file, since hidde
james 2011-06-03 14:48:59 -0700 (Fri, 03 Jun 2011) 124 Don't save "hidden" property for NPC locations in RSAV file, since hiddenness is always recalculated from tags after a load --- U wip/savegame.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: jay/4381 Getting it closer to actually working (doesn't crash anymore, but it isn
On 03/06/2011 2:34 PM, Jay Tennant wrote:
From: Ralph Versteegen
Sent: Friday, June 03, 2011 11:47 AM
On 3 June 2011 06:00, Jay Tennant wrote:
From: subvers...@hamsterrepublic.com
Sent: Thursday, June 02, 2011 12:45 PM
To: ohrrpgce@lists.motherhamster.org
Subject: [Ohrrpgce] SVN: jay/4381 Getting it closer to actually working
(doesn't crash anymore, but it isn
jay
2011-06-02 10:45:09 -0700 (Thu, 02 Jun 2011)
94
Getting it closer to actually working (doesn't crash anymore, but it isn't
drawing right yet).
Oh, it's drawing *mostly* correct. That's encouraging! :)
Sounds good! So do you have a test program? Actually, I'll add a
function to allmodex.bas to draw transformed rects, and can stick a
test of it in the 'secret_menu' in custom.
I'm running a test program of it right now, but it's so disappointing: the
overflow problem. If I have a fixed point number divided by a very small
fraction (say 1/65536th) I get a terribly inaccurate number. I don't want
to switch to floating point, but I don't think I have much choice. Is there
a solution to this that I'm not getting?
Where the issue arises: the rasterizer evaluates a surface to be drawn to
one line at a time. The first pass is simply to figure what range of pixels
on each line is to be evaluated. The second pass (after all line's pixel
ranges are figured) is to interpolate the edge values across the line for
each pixel. The error is occurring during the first pass, in figuring the
left-most and right-most boundary of a line of pixels to be rasterized.
For each line, I take the slope of the edges of the triangle and find all
x-intercepts. The left-most intercept and the right-most intercept
(as long as they're within range of the triangle) are the boundaries of
the pixels.
I realize they're some optimizations I could perform (like calculating the
edge slopes once), but the error occurs when an edge is almost completely
vertical. The fixed point integer can't represent +/- infinite, so an
overflow/underflow occurs in determining slope (dy / almost 0).
I think the solution is using floating point math for this section. Can
you think of another solution? Other than that, the rasterizer's working
pretty nicely. I'll commit the code when I'm able to.
Does you algorithm allow for swapping axes? Eg,
if(dy > dx) {
//swap values, and flip the result turn-ways
}
I don't know if this is possible in your case, however.
--
- Mike Caron
___
Ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: jay/4381 Getting it closer to actually working (doesn't crash anymore, but it isn
> From: Ralph Versteegen > Sent: Friday, June 03, 2011 11:47 AM > > On 3 June 2011 06:00, Jay Tennant wrote: > >> From: subvers...@hamsterrepublic.com > >> Sent: Thursday, June 02, 2011 12:45 PM > >> To: ohrrpgce@lists.motherhamster.org > >> Subject: [Ohrrpgce] SVN: jay/4381 Getting it closer to actually working > >> (doesn't crash anymore, but it isn > >> > >> jay > >> 2011-06-02 10:45:09 -0700 (Thu, 02 Jun 2011) > >> 94 > >> Getting it closer to actually working (doesn't crash anymore, but it isn't > >> drawing right yet). > > > > Oh, it's drawing *mostly* correct. That's encouraging! :) > > Sounds good! So do you have a test program? Actually, I'll add a > function to allmodex.bas to draw transformed rects, and can stick a > test of it in the 'secret_menu' in custom. I'm running a test program of it right now, but it's so disappointing: the overflow problem. If I have a fixed point number divided by a very small fraction (say 1/65536th) I get a terribly inaccurate number. I don't want to switch to floating point, but I don't think I have much choice. Is there a solution to this that I'm not getting? Where the issue arises: the rasterizer evaluates a surface to be drawn to one line at a time. The first pass is simply to figure what range of pixels on each line is to be evaluated. The second pass (after all line's pixel ranges are figured) is to interpolate the edge values across the line for each pixel. The error is occurring during the first pass, in figuring the left-most and right-most boundary of a line of pixels to be rasterized. For each line, I take the slope of the edges of the triangle and find all x-intercepts. The left-most intercept and the right-most intercept (as long as they're within range of the triangle) are the boundaries of the pixels. I realize they're some optimizations I could perform (like calculating the edge slopes once), but the error occurs when an edge is almost completely vertical. The fixed point integer can't represent +/- infinite, so an overflow/underflow occurs in determining slope (dy / almost 0). I think the solution is using floating point math for this section. Can you think of another solution? Other than that, the rasterizer's working pretty nicely. I'll commit the code when I'm able to. ___ Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting http://www.doteasy.com ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/4377 savemapstate_npcl() now stores NPC locations using a RELOAD format
On Sat, Jun 04, 2011 at 04:25:18AM +1200, Ralph Versteegen wrote: > On 3 June 2011 03:36, James Paige wrote: > > On Thu, Jun 02, 2011 at 08:08:12PM +1200, Ralph Versteegen wrote: > >> On 2 June 2011 16:06, wrote: > >> > james > >> > 2011-06-01 21:06:57 -0700 (Wed, 01 Jun 2011) > >> > 157 > >> > savemapstate_npcl() now stores NPC locations using a RELOAD format > >> > (in addition to the old format, since the reader for RELOAD NPC > >> > locations isn't done yet) > >> > --- > >> > U wip/udts.bi > >> > U wip/yetmore2.bas > >> > U wip/yetmore2.bi > >> > >> Oh yeah, that other thing I wanted to say: saved map states are meant > >> to store all the other data in NPCInst too, even xgo, ygo (although > >> it's really unlikely anyone depends or has noticed that). Definitely > >> the frame though. > >> In fact, we'll want to store ignore_walls, not_obstruction, > >> suspend_ai, suspend_use in the replacement for .L lumps too, because > >> all of those are meant to be editable in the map editor. > > > > Okay, I can add all that stuff. I left out xgo and ygo because it > > appears they get wiped out on map load, but that could be changed in the > > future. > > > > --- > > James > > Actually, don't bother. Because all this has already been implemented > before! See gamestate_npcs_to/from_reload! Embarrassing... we each > wrote part of each of those :) It was partially poor updating of the > wiki which let us down. Haha! Wow. However, I am not sure sure I want to use that exact same code... the rsav_warn_error shouldn't be used in non-rsav contexts... but I am sure I can think of some way to deal with that... Hmmm... --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: jay/4381 Getting it closer to actually working (doesn't crash anymore, but it isn
On 3 June 2011 06:00, Jay Tennant wrote: >> From: subvers...@hamsterrepublic.com >> Sent: Thursday, June 02, 2011 12:45 PM >> To: ohrrpgce@lists.motherhamster.org >> Subject: [Ohrrpgce] SVN: jay/4381 Getting it closer to actually working >> (doesn't crash anymore, but it isn >> >> jay >> 2011-06-02 10:45:09 -0700 (Thu, 02 Jun 2011) >> 94 >> Getting it closer to actually working (doesn't crash anymore, but it isn't >> drawing right yet). > > Oh, it's drawing *mostly* correct. That's encouraging! :) Sounds good! So do you have a test program? Actually, I'll add a function to allmodex.bas to draw transformed rects, and can stick a test of it in the 'secret_menu' in custom. ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/4377 savemapstate_npcl() now stores NPC locations using a RELOAD format
On 3 June 2011 03:35, James Paige wrote:
> On Thu, Jun 02, 2011 at 07:51:02PM +1200, Ralph Versteegen wrote:
>> On 2 June 2011 16:06, wrote:
>> > james
>> > 2011-06-01 21:06:57 -0700 (Wed, 01 Jun 2011)
>> > 157
>> > savemapstate_npcl() now stores NPC locations using a RELOAD format
>> > (in addition to the old format, since the reader for RELOAD NPC locations
>> > isn't done yet)
>> > ---
>> > U wip/udts.bi
>> > U wip/yetmore2.bas
>> > U wip/yetmore2.bi
>>
>> I'm getting really sick of these RELOAD <--> UDT conversion functions,
>> we need to improve things. Now we could add more convenience functions
>> to the RELOAD API (though in general you can't get too far in a
>> language that doesn't have proper macro support, or at least
>> iterators).
>> Part of the problem is that the
>> *extras [null]
>> **extra [int] - extra no.
>> ***int [int] - value
>> style results in lengthy reading/writing code. (Recall that I am to
>> blame for this suggestion, because naming a node "extra#" results in
>> even uglier (at least conceptually) reading code.) Here's the code for
>> this:
>>
>> IF .extra(0) <> 0 ORELSE .extra(1) <> 0 ORELSE .extra(2) <> 0 THEN
>> DIM extras AS NodePtr
>> extras = CreateNode(n, "extras")
>> FOR j AS INTEGER = 0 TO UBOUND(.extra)
>> IF .extra(j) <> 0 THEN
>> DIM exnod AS NodePtr
>> exnod = AppendChildNode(n, "extra", j)
>> SetChildNode(exnod, "int", .extra(j))
>> END IF
>> NEXT j
>> END IF
>>
>> (Note the bug: the 'extras' variable isn't used). Adding some simple
>> functions to the API gives:
>
> Oops! haha! And I used CreateNode, which creates an unparented node,
> instead of AppendChildNode which I meant to use. Thanks for spotting
> that.
>
>> DIM extras AS NodePtr
>> extras = CreatePossibleNode(n, "extras")
>> FOR j AS INTEGER = 0 TO UBOUND(.extra)
>> IF .extra(j) <> 0 THEN AppendKeyValue(extras, "extra", j, .extra(j))
>> NEXT j
>> Or even better, IMO:
>>
>> FOR j AS INTEGER = 0 TO UBOUND(.extra)
>> AppendPairIfNonzero(n, "extras/extra", j, .extra(j))
>> NEXT j
>>
>
> That looks slick!
>
> The current RELOAD <-> UDT subs don't bother me that much because they
> are already orders of mangitude better than the old binary save/load
> code in terms of readability and extendability, so I am already happy,
> but these api suggestions make me even happier :)
Since my lectures for the semester finished yesterday, I'm relaxing
for a (short) bit with OHR work. I'm working on these helper
functions.
>> But maybe we should switch to automatically generated
>> serialisation/deserialisation functions, like protobufs does:
>> http://code.google.com/apis/protocolbuffers/docs/overview.html
>> It shouldn't be much work to write a code generator. I can
>> reuse/continue my partial FB parser, after all, and it's far less
>> buggy than the official fbc parser. :) It could use either annotated
>> UDT declarations (where the new keywords are #defined to nothing so FB
>> ignores them):
>>
>> TYPE NPCInst
>> '...
>> extra(2) as integer SaveAs("extras", Optional)
>> END TYPE
>
> That is dang interesting!
>
>> or for additional flexibility, we could instead create sweet
>> syntactical sugar, and expand it out with a preprocessor (my FB parser
>> was aware of variable types so could do this):
>>
>> FOR j AS INTEGER = 0 TO UBOUND(.extra)
>> IF .extra(j) THEN n.extras.extra(j) = .extra(j)
>> NEXT
>>
>> 'later, reading back:
>>
>> FOR j AS INTEGER = 0 TO UBOUND(.extra)
>> .extra(j) = WithDefault(n.extras.extra(j), 0)
>> NEXT
>>
>> or perhaps a combination of the two: annotate udts, and use that data
>> when instructed to read or write:
>>
>> WriteReload(npcinst, n, "extras") 'UDT members referred to by node name
>> ReadReload(npcinst, n, "extras")
>>
>> Come to think of it, this would be equivalent to creating a new
>> programming language which is translated to FB. Which would be a
>> half-way step to translating to C++ :)
>
> On my first read through this sounded pretty alarming. I read through
> again, and I think I get it. This sounds cool.
If you think that's scary, you don't want to hear about a project I'm
considering: creating a C variant more suitable for implementation of
VMs (based on llvm/clang with custom optimisation passes)... told you
you didn't want to hear :)
> I am going to continue working on the NPC saving/loading as I am doing
> right now, but this stuff sounds great.
>
> ---
> James
> ___
> Ohrrpgce mailing list
> ohrrpgce@lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
___
Ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/4377 savemapstate_npcl() now stores NPC locations using a RELOAD format
On 3 June 2011 03:36, James Paige wrote: > On Thu, Jun 02, 2011 at 08:08:12PM +1200, Ralph Versteegen wrote: >> On 2 June 2011 16:06, wrote: >> > james >> > 2011-06-01 21:06:57 -0700 (Wed, 01 Jun 2011) >> > 157 >> > savemapstate_npcl() now stores NPC locations using a RELOAD format >> > (in addition to the old format, since the reader for RELOAD NPC locations >> > isn't done yet) >> > --- >> > U wip/udts.bi >> > U wip/yetmore2.bas >> > U wip/yetmore2.bi >> >> Oh yeah, that other thing I wanted to say: saved map states are meant >> to store all the other data in NPCInst too, even xgo, ygo (although >> it's really unlikely anyone depends or has noticed that). Definitely >> the frame though. >> In fact, we'll want to store ignore_walls, not_obstruction, >> suspend_ai, suspend_use in the replacement for .L lumps too, because >> all of those are meant to be editable in the map editor. > > Okay, I can add all that stuff. I left out xgo and ygo because it > appears they get wiped out on map load, but that could be changed in the > future. > > --- > James Actually, don't bother. Because all this has already been implemented before! See gamestate_npcs_to/from_reload! Embarrassing... we each wrote part of each of those :) It was partially poor updating of the wiki which let us down. ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
