Version 2.3 Feature Suggestions

[Plush]

More suggestions to HTML5 (Which I'm implementing myself using hacky approaches):

Can you switch to typed arrays for maps? This is a fairly new addition to Javascript. Also use them for ImageData for ModulateColor tinting..?

Can you replace the TestCollisionRect function with one that only scans from a list of proximal sprites in a region (IE grid based sprite collisions that only search buckets, rather than entire maps. This is similar to spatial hashing collisions) such as TestCollisionProximal?

[bluemonkmn]

I don't know how to iterate proximal sprites without spatial hashing, and spatial hashing seems like it would significantly complicate sprite collections. Spatial hashing could significantly increase the overall number of sprites that SGDK2 can handle in general, but having no experience in implementing it, it might take me quite a while to get it right. It might also introduce the desire for configurable values to indicate whether to exclude off-screen sprites from all processing. I expect more time would be spent on other processing of sprites besides just collision detection. This might be part of the reason I haven't implemented it -- I don't want to be penny wise and pound foolish on the optimizations.

I haven't encountered any SGDK2 games that require this degree of optimization, so it would be hard to make sure I'm optimizing appropriately. My hope was that dividing sprites into categories would be a sufficient optimization in this regard. By putting sprites into sufficiently narrow categories, you significantly limit the number of sprites you need to loop through when checking for collisions because each category is its own array. Is there any way you can use the existing sprite category constructs to sufficiently optimize your sprite interactions?

The same could be said for typed arrays. I haven't encountered anyone hitting any actual issues due to the internal format of the layer tile storage, so it's hard to know the real impact or value of this outside of theoretical calculations (and I tend to follow the principle of optimizing only when and where necessary). I can't remember if I was aware of JavaScript typed arrays when implementing HTML5 support, or maybe I wanted to support older browsers (was HTML5 introduced before typed arrays?), but the question does arise what the real trade-off would be in simplicity versus performance. Are you running out of memory?

[bluemonkmn]

Can you implement typed array storage for your map layers by just replacing 2 lines in the MapLayer.js file in your SourceCode folder in your SGDK2 project? Replace

Code: [Select]

var result = new Array();
with this in decodeData1:

Code: [Select]

var buf = new ArrayBuffer(data.length);
var result = new Uint8Array(buf);
and this in decodeData2:

Code: [Select]

var buf = new ArrayBuffer(data.length);
var result = new Uint16Array(buf);


[Plush]

Hello, bluemonkmn,

I shouldn't post my questions here in this thread. However, thank you for the support.

[bluemonkmn]

I split the topic and moved it to an appropriate location to fix that.

[Plush]

Hi, can we possibly modify the automatically generated code that SGDK2 makes for HTML5 projects within the IDE?

Code: [Select]

function GraphicSheet(image, cellWidth, cellHeight, columns, rows) {
 
this.image = new Image(); //load a new image object
 
//AJAX Image Loading
var xhr = new XMLHttpRequest();
var img = this.image;
xhr.open("GET", image.src, true);
xhr.responseType = "arraybuffer";
xhr.onload = function (e)
{
var arrayBufferView = new Uint8Array(this.response);
blob = new Blob([arrayBufferView], {type:"image/png"});

    var urlCreator = window.URL || window.webkitURL;
    img.src = urlCreator.createObjectURL(blob); //set the src to the url of the image
}
xhr.send();

this.cellWidth = cellWidth;
   this.cellHeight = cellHeight;
   this.columns = columns;
   this.rows = rows;
}
Here is some JS code for initializing GraphicSheets() using AJAX.
JSPerf says this may be faster on mobile devices.

I don't know if its any more performant than the existing code.

SGDK2 doesn't give you dynamic control of when you can load graphicsheets into memory and unload them with HTML5 unless you modify the code of the project after it has been generated in HTML5 form.

Base64 URI's are very inefficient for html5, but I'm glad that SGDK2 doesn't use WebGL. I guess this is the stage where loading images from actual URL's comes in handy, but it's still very slow..
See

https://jsperf.com/drawimage-whole-pixels/27

This jsPerf is poorly constructed so its hard to tell whether the improvement is only because of the code's format, the loading time or a blobURL, or w/e. It's also hard to tell whether drawImage is affected by having its source as a blobURL or as a webURL, base64 URL, w/e.

Please run that jsPerf on an android phone or tablet. Please let me know what you get. The performance of drawImage for weburl/base64 seems to be reduced on mobile compared to PC but the images seem to do better with blobs.

I also recall correctly that SGDK1 used solid colors for transparency. This was possible because of the BMP format that graphics were stored within.

Maybe JPEG could be used with SGDK2 (Without having to hack)?

This would be difficult to do with JPEG because of how JPEG seems to add compression "artefacts" (sic) to images and these artefacts seem to reduce the potential of generating clean outlines, but it seems that JPEGs would also be a viable option for graphicsheets, since they're much faster to draw.

SGDK2 seems that it may need some changes to make it even better suited for HTML5 projects.

ah but then again this would require me to apply this change for a version of SGDK2 that didn't use all of the new lighting effects because of my hardware, maybe I should just look at the github.. :>

another part of this is just my thoughts on an optimization to using drawImage from various image sources

I think you mentioned earlier bluemonkmn, that you would have to remake the priority system of the layers just to have 0 priorities, but... maybe the entire graphic system of SGDK2's HTML5 projects could be changed to dynamically load graphic sheets in game?

Something like referencing and dereferencing GraphicSheets, or finding a way to speed up drawing would be nice, especially since some of us here quietly have large projects.

EDIT: I've noticed that using ~~ with coordinates fed into drawImage seems to make the game run more smoothly and prevents as many chops and lags when scrolling, it may just be me though.

[bluemonkmn]

If you un-check the box for embedding the images in the HTML, then you will get code like this:

Code: [Select]

<img id="CoolFont" style="display:none" src="CoolFont.png" />
<img id="FireFont" style="display:none" src="FireFont.png" />
<img id="Lettering" style="display:none" src="Lettering.png" />
<img id="SHFL32x32" style="display:none" src="SHFL32x32.png" />
<img id="SHFLPlatform" style="display:none" src="SHFLPlatform.png" />
<img id="SHFLSprites" style="display:none" src="SHFLSprites.png" />

instead of code like this:

Code: [Select]

<img id="CoolFont" style="display:none" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAATgAAABICAYAAABiKukfAAAAAXNSR0IArs4c6QAAAARnQU1BAACx
...
GNkrX2VeTJAPAKoWmeL6TluKvyNTDzn1a+Lh7zkM/A/wbs0ciKuS5wAAAABJRU5ErkJggg==" />
<img id="FireFont" style="display:none" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAATgAAABICAYAAABiKukfAAAAAXNSR0IArs4c6QAAAARnQU1BAACx
...

But I don't quite understand the concern over the performance of the initial load. That's something that shouldn't be happening that often, and the difference between different methods shouldn't be humanly noticeable if it's happening only occasionally, should it?

Of course, all the SGDK2 code is available if you want to change the generated code. The only way to change code not visible in the project tree is after it's generated or by changing the generator. Although you might be able to circumvent it with some JavaScript tricks that override inherited base behavior, I don't have any specific ideas there.

My jsperf tests on a Google Nexus 6P are:
image from URL: 7,897
image from base64 jpeg: 474
image from base64 png: 47
image from blob_url: 6,158
image from blob: 123

I also don't understand how you come to the conclusion that JPEGs are faster to draw. I thought we were talking about loading speed, not drawing speed. And once the image is loaded, there should be little memory of the original format of an image. The only impact on drawing speed I might expect would be based on whether there are translucent and transparent pixels in the data. Have you done any tests of JPG drawing vs PNG drawing? You should just be able to replace the PNG files generated by the HTML code generator with JPG files for a test.

Dynamically loading graphic sheets would slow things down wouldn't it? Is your project so large that you can't fit all the graphics in memory? Would it make sense to split the project into separate HTML files so when you reach a certain point, you navigate to another HTML file? Otherwise, I'm not sure how to unload graphics.

In general, I'm wondering what is driving this need to optimize. Are you sure the problems you're trying to solve are the problems causing your performance issues, assuming you are even observing performance issues? Have you used Chrome's performance profiling features to check where performance is an issue?

What is "~~"?

[Plush]

In general, I'm wondering what is driving this need to optimize. Are you sure the problems you're trying to solve are the problems causing your performance issues, assuming you are even observing performance issues? Have you used Chrome's performance profiling features to check where performance is an issue?

What is "~~"?

ctx.drawimage is most definitely the problem. Something about it seems to be causing the game to lag. This is most noticeable when you draw tons of tiles.

SGDK2 is telling me that drawing  large images is faster than drawing multiple smaller images.

That doesn't make any sense to me because every JSPerf out there says drawing subimges of an image is slightly faster than drawing one huge image!

So I glanced at the Frame.draw function and slapped myself for not seeing the solution sooner!

I've discovered SGDK2's issue here, subpixels.

1. We need to disable image smoothing in the context.
2. All coordinates/parameters that are passed to drawimage should be wrapped with ~~.

https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Optimizing_canvas

This article states it directly as the second bulletpoint

~~ is my favorite operator that is similar to Math.floor() for "int" conversions. It's what I use to fix the coordinates and attempt to alleviate the lag. I've noticed less lag and slowdown when drawing high-density tile regions and ive managed to speed up X/Frame.draw.

Because of the subpixels (When sprites or layer.currentX/Y is in a non-integer location, drawImage has to perform extra unnecessary calculations.. which I suppose is causing the slowdown.

Try ~~ for yourself with a game that has tons of tiles/sprites with floating point positions on mobile.

https://jsperf.com/drawimage-whole-pixels/45 proof
https://jsperf.com/drawimage-whole-pixels/42

Next

One of my issues with dynamically loading Graphics is the way that SGDK2 handles modulate colors.

I know the difference between image url's and the base64 embeds. That isn't enough for me and I'm sorry for not being more clear, it isn't the issue. I currently use very large graphics 1024x768 and use color modulation for maaaaaaaaaaany frames of these large graphics... such as large high resolution color changing backgrounds and have many within my game, which make many calls to the ModulateCelColor function in Frame.js.. The repeated use of getImageData/putImageData creates garbage (at a glance, similar to memory leak, but it actually gets recycled at a certain plateau, 200MB on pc) so this is a known issue in Chromium.

https://bugs.chromium.org/p/chromium/issues/detail?id=242215

Imagine this now with a new Typed array of 1024x768 bytes for each frame.

You'll get nice little error in Firefox eventually which happens for me, which makes your project unable to load.

Look in Frame.js and see where and why.

document.write('Failed to process images. This may occur when running from local files; see <a href="http://stackoverflow.com/questions/2704929/uncaught-error-security-err-dom-exception-18">see details</a>');

The try/catch tells us this. Okay!

Except, that isn't the error, is it?

Nope. What?

There's a memory limit and I've quickly hit it in Firefox, even with base64 embeds.. so I know it can't be that security issue.

So I've just removed color modulation from my project altogether by removing that function, and no more issues on mobile...  and no more weird "security issue" in Firefox which isn't really a security issue at all but a memory issue!

Too bad for that actually.

It would be really nice to be able to control when and where these things happened.



Next

Another bulletpoint from the optimize canvas article is that transparent canvases are inherently slower to draw to.

Your points are correct.. my understanding of PNG/JPEG transparency would tell me that JPEG would be faster to draw, lacking the transparency of PNG and not needing sophisticated color blending, and since opaque canvases are faster.

So I created a performance test on jsperf to investigate

https://jsperf.com/png-vs-jpg-drawimage/1



In this test case, I was incorrect, surprising me. It turns out that PNG was faster.

Perplexed, I ran another test, this time, trying to take advantage of the fact that PNG has transparency and this matters more when overlapping images, so I made multiple in-place runs of drawImage.



JPEG was faster in the second test.. But not by much. They seem very close with performance differences mainly due to error.

I wanted to stress test it even further.. so I did this in a loop of 150 images... ( a real environment)



JPEG was once again faster.. but not by much!

----------------

I've sped up my performance on phone a tad mainly with double tildes. If you'd like, look into it the ModulateCelColor issue I mentioned also. PNG/JPEG isn't an issue.

Great engine btw!

To tell you the truth, I've been using this engine since it was released a decade ago but without ever registering here...

The HTML5 stuff isn't difficult but it isn't as good to me as the C# code (OpenTK, or even the prior DirectX code)

I'm sorry for disturbing you so much, We're really pushing it to its limit with all of the modifications/ custom JS code I'm adding (Our game really strains SGDK2 because we're trying to make SGDK2 into a 2.5D Sega Saturn on steroids with HTML5). So any optimization is good to me right now..

I've modified the code so much the only thing I use SGDK2 for is just project management of assets. Nearly all of the code I'm using now is very different from SGDK2.. The original code was useful for prototyping our project.

Despite using entirely different .js files, the SGDK2 project still loads and exports. I like the open source-ness of this engine!

[bluemonkmn]

I think the performance issue with drawImage would only affect sprites because I think tiles are already drawn at integral positions. But if you have a lot of sprites, I suppose that could be an issue. I think my thought at the time was that slow-moving sprites could actually benefit visually from drawing at non-integral positions.

Unfortunately, SGDK2 wasn't designed for heavy-duty game development. Or you have to be pretty smart about how you use it if you're going to seriously load it down with a huge project. As you've seen, color modulation is a big problem if you're trying to modulate a lot of graphics to a lot of colors in an HTML5 project since HTML5 doesn't appear to support real-time color modulation.

Glad you still find it somewhat useful, though.

[Plush]

Happy Holidays:

1. We're investigating fast color modulation through a Javascript PNG library.

The central idea is to convert the base64 DataURI into readable PNG data, and then a TypedArray directly, without using getImageData. This allows us to have better control of when we allocate and deallocate the array of pixel data.

(We plan to then load and delete the transformed data using a loadModulateFrame() function in Plan.js.)

2. We're far from real time color modulation, but we've achieved real time palette swaps (The kind old games used for things like waterfalls) and we're hoping that the above method will solve the growing memory issue found with getImageData.

Our current system may allow real-time palette swapping rather than color modulation, we we find this more useful.

3. One idea for real time color modulation I had was to possibly copy the graphic onto an offscreen canvas, use FillRect a few times with different gCO modes, then copy back to the game canvas. Please let me know what you think, I don't understand these very well:

https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/globalCompositeOperation

I've played around with these, and gotten all of them to work, and I know that there's SOME combination which can be used for color modulation. I'm not sure which though. You probably can find out..

So far I've done fast color tinting, desaturation, brightening, darkening (burn), and light bloom.

4. When attempting to use sprite parameters (param) for HTML5, you have to encapsulate everything in this. (this.param).

The code generator usually picks up on these, but there are instances:

param+3

Where if the parameter is the operand of an expression, the "this." won't be prefixed to the beginning of the parameter.

You could maybe make a note of that to new developers because sometimes the HTML5 code generator makes these variables global scope by doing nothing, and the game will misbehave because you're expecting a sprite parameter (this.) not a global variable.

On the converse, this is useful because if you know this, you can access global and local variables without having everything forced to local (sprite instance) scope.

The lack of this automatic restriction also means you can inject custom javascript and never have to worry about the code generator interfering.

Sprite Rule:
Do (=)
0; console.log("Hello")
Output
dummyvar

Would store 0 to dummyvar and also print "Hello" in console, and is very useful for debugging!

5. I would never say that SGDK2 isn't ready for hardcore game development. It's all about HOW ITS USED.

Everything in your engine is perfect.

Perfect.

Perfect for making any project and so far I haven't had any issues with limitations. This engine is much better than Unity in my opinion and I feel it's the perfect tool for game development. It's organized, intuitive, and if there's an issue, the code can always be changed!

I've managed to do the impossible and get fully 3D maps and models working in SGDK2 with HTML5.

The reason I say its perfect is because Unity, GMS, Fusion, and GoBot are either just badly written, restrictive, or bloaty. I can change everything in this and I love it completely. The IDE is the best for game development that I've ever used.

Please never stop working on SGDK2,

Also, related

https://29a.ch/2010/3/24/normal-mapping-with-javascript-and-canvas-tag

I hope this is useful to you. I have no reason to use lighting effects with normalmapping, since I have a fully 3D pipeline in canvas2D, but it could work in a new update of sgdk2.

EDIT:

Another thing I've mentioned earlier was a framerate issue...

You said it was a non issue. The thing about that is that the browser may sometimes be forced to reflow a page before drawing is complete, you can see warnings of this in the console as the setInterval/setTimeout functions are taking too long. This situation creates throttling where the browser is forced to quit and start another logic execute/animation paint before finishing the current frame.

https://stackoverflow.com/questions/29480204/moving-from-setinterval-method-to-requestanimationframe-with-sprite

This leads to a wildly unpredictable refresh rate for the screen which I'm observing... it's more noticeable on non-PC devices and low end consumer electronics like older tablets and phones.

Version 2.3 should probably use refreshAnimationFrame() rather than setInterval/setTimeout.

Finally, you should consider adding more exporters than the HTML5 exporter. An HTML5 project can be exported across multiple devices through the use of tools such as ionic and phonegap.

It's very sad to see SGDK2 which has so much potential gathering dust and not widely discussed in the same breath as Godot, which IMO isn't as good as your code, when I can very quickly and easily port these HTML5 projects to other platforms with very little changes to the code.

I can contribute to this feature if you don't have the time. I've exported my current project to Android, iOS, Windows, Wii-U, and Blackberry with no issue. I have yet to test on other platforms..

[bluemonkmn]

3. One idea for real time color modulation I had was to possibly copy the graphic onto an offscreen canvas, use FillRect a few times with different gCO modes, then copy back to the game canvas. Please let me know what you think, I don't understand these very well:

https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/globalCompositeOperation

I've played around with these, and gotten all of them to work, and I know that there's SOME combination which can be used for color modulation. I'm not sure which though. You probably can find out..

So far I've done fast color tinting, desaturation, brightening, darkening (burn), and light bloom.

I feel like multiply is pretty close to what I was doing, but hue looks pretty close to what I thought color modulation did, and what I was trying to accomplish (re-coloring existing graphics without affecting intensity etc).

5. I would never say that SGDK2 isn't ready for hardcore game development. It's all about HOW ITS USED.

Everything in your engine is perfect.

Perfect.

...
Please never stop working on SGDK2,

Such high praise -- and I very much appreciate it. Too bad it's after so much of SGDK2 has left my brain and been left in the past. I will keep your comments in mind as I consider where to invest efforts in the future, though. Perhaps I will yet find time to further develop SGDK2... like I did with lighting effects. There are at least a couple hangers-on (including you) giving me some motivation to keep it alive. Thank you.

Another thing I've mentioned earlier was a framerate issue...
...
Version 2.3 should probably use refreshAnimationFrame() rather than setInterval/setTimeout.

I'm confused how a different method of pushing animation could make much difference. If there's too much to do within 1/30th of a second (or whatever your frame rate is) there's not much you can do to save it. But I guess there could be some more subtle differences that would make requestAnimationFrame more consistent than setInterval. Again, I put less time (and experience) into the HTML5 code than into the C# code, but will try to remember this for future updates. Sounds like the right thing to do.

Finally, you should consider adding more exporters than the HTML5 exporter. An HTML5 project can be exported across multiple devices through the use of tools such as ionic and phonegap.

Did you notice the Mobile Device sample project, which is essentially an HTML5 project designed for a mobile device interface. Is that the kind of thing you're talking about?

[Plush]

Such high praise -- and I very much appreciate it. Too bad it's after so much of SGDK2 has left my brain and been left in the past. I will keep your comments in mind as I consider where to invest efforts in the future, though. Perhaps I will yet find time to further develop SGDK2... like I did with lighting effects. There are at least a couple hangers-on (including you) giving me some motivation to keep it alive. Thank you.

No problem, I love this engine. What you've done by making this open source is selfless. You're a really good person.

I know you're busy now, and don't have time to rebuild this community again, but it wouldn't be difficult. Have you ever considered a SGDK3 (With some possible 3D support in both C# and HTML5)?

I'm confused how a different method of pushing animation could make much difference. If there's too much to do within 1/30th of a second (or whatever your frame rate is) there's not much you can do to save it. But I guess there could be some more subtle differences that would make requestAnimationFrame more consistent than setInterval. Again, I put less time (and experience) into the HTML5 code than into the C# code, but will try to remember this for future updates. Sounds like the right thing to do.

Code: [Select]

 
function fnAnimate(timestamp){
gameDraw();
     
   if (timestamp < lastFrameTimeMs + (40)) { 
      //if (draw3D != -1)
   
      requestAnimFrame(fnAnimate);
   return;   
   }    lastFrameTimeMs = timestamp;
   
gameUpdate();

requestAnimFrame(fnAnimate);
   };
This is the asynchronous game loop we're using rather than calling pulse() with setInterval, it draws to the screen much more frequently (when the window is ready) than it updates game logic, which is rate limited by the FPS. The timestamp is a value passed into the callback of fnAnimate.

gameDraw() and gameUpdate() are just the respective map drawing and map updating functions taken from pulse();

Even if the game lags (Due to the mobile operating system running background processes sometimes), the display still appears smooth and responsive!

It's not good, but I hope it gives an idea of what I mean.

Did you notice the Mobile Device sample project, which is essentially an HTML5 project designed for a mobile device interface. Is that the kind of thing you're talking about?

It's a good start.

A. It would be nice if the controls were represented as separate objects (Possibly overlaid canvases) which would allow us to bind separate asynchronous event listeners to them with Hammer.js. Using a fun library like Hammer.js you can have all sorts of cool browser events such as multitouch, panning, and even rotate. It even has polyfills for browsers that don't support the fancy touch stuff. We're using it right now with great results on all devices, and falling back to mouseInfo for the PC port.

B. SGDK2 uses a single mouseInfo event listener. This causes problems with multiple touch operations.

C. Canvas and touch events don't scale on multiple devices, or when the canvas is at the center of the screen. This can be fixed with modifying the style attribute, but the mouseInfo event listener is still hard coded to calculate its position regardless of where it is. (Maybe it's my version of SGDK2, I'm looking at some of the newer versions and see that you might have fixed this)

D. The HTML5 is useful, but for an exporter, it would be so nice if we were given an APK or some kind of device specific binary. Tools such as Crosswalk/PhoneGap can automatically generate an APK given a directory of HTML files. They can also generate binaries for any platform.

For instance, native audio is the best audio, but not all browsers can handle web audio (Older android webviews can't). An exporter is good for making a hybrid between HTML5 and native features

EDIT: Another thing I've noticed is that using XFrames is much faster and smoother than drawImage. This is because canvas copying seems to be faster than drawing images..

https://jsperf.com/draw-canvas-vs-draw-image/2

Perhaps you could use XFrames by default? I see no reason to continue to use Frame. Or, the SGDK2 user could just modify modulate alpha values by a bit (255->254) to turn Frames into XFrames

This should be a note, we need a separate thread for these optimization ideas.

[bluemonkmn]

I don't understand your reasoning behind XFrame performance being related to drawImage from a particular kind of source. XFrame and Frame both use drawImage, and both come from a graphic sheet image. However XFrame and Frame can both come from modulated images on a canvas or original images directly in the the IMG element. Is it possible the performance is related to modulated frames (from a canvas) and not to XFrame versus Frame? The only difference with XFrame is that they can have 2D transforms applied at runtime. Color modulations are not 2D transforms, and can apply to XFrames or Frames.

[Plush]

Color modulations are not 2D transforms, and can apply to XFrames or Frames.

I see, ook. Here I was seeing in my project that all of the color modulated graphics became XFrames. I don't see any that are still Frames.

The performance boost I was referring to was just my idea that all XFrames that are sourced from an offscreen canvas so they are faster to draw, but I didn't know that some XFrames can come directly from IMG elements as well.

How does one manually force a Frame to be drawn as an XFrame (a canvas sourced one) then? Just modify the transform values?

[bluemonkmn]

I think you originally had the right idea. Your new idea is more confused than your initial understanding:

• Frames are for drawing graphics (from canvas or IMG source) that have not been transformed by a 2D transform.
• XFrames are for drawing graphics (from canvas or IMG source) that have been transformed by a 2D transform.
• Graphics that have been affected by color modulation are drawn from a canvas (as XFrame or Frame).
• Graphics that have not been affected by color modulation are drawn from an IMG source (as XFrame or Frame).

Therefore, if you want to force graphics to be drawn from a canvas, just touch the color modulation. This will not affect whether it is a Frame or an XFrame, but it will affect whether the image source of that Frame or XFrame is coming from a canvas or an IMG, which I think is your goal.