Differential D4830 Diff 21079 source/renderer/backend/IDevice.h

Changeset View

Standalone View

View Options

source/renderer/backend/IDevice.h

Show First 20 Lines • Show All 66 Lines • ▼ Show 20 Lines

public:

virtual const std::string& GetName() const = 0;

virtual const std::string& GetVersion() const = 0;

virtual const std::string& GetDriverInformation() const = 0;

virtual const std::vector<std::string>& GetExtensions() const = 0;

virtual void Report(const ScriptRequest& rq, JS::HandleValue settings) = 0;

virtual IFramebuffer* GetCurrentBackbuffer() = 0;

virtual std::unique_ptr<IDeviceCommandContext> CreateCommandContext() = 0;

virtual std::unique_ptr<ITexture> CreateTexture(

const char* name, const ITexture::Type type, const uint32_t usage,

const Format format, const uint32_t width, const uint32_t height,

const Sampler::Desc& defaultSamplerDesc, const uint32_t MIPLevelCount, const uint32_t sampleCount) = 0;

virtual std::unique_ptr<ITexture> CreateTexture2D(

const char* name, const uint32_t usage,

const Format format, const uint32_t width, const uint32_t height,

const Sampler::Desc& defaultSamplerDesc, const uint32_t MIPLevelCount = 1, const uint32_t sampleCount = 1) = 0;

/**

* @see IFramebuffer

* The color attachment and the depth-stencil attachment should not be

* nullptr at the same time. There should not be many different clear

* colors along all color attachments for all framebuffers created for

* the device.

* @return A valid framebuffer if it was created successfully else nullptr.

virtual std::unique_ptr<IFramebuffer> CreateFramebuffer(

const char* name, ITexture* colorAttachment,

ITexture* depthStencilAttachment) = 0;

const AttachmentLoadOp colorAttachmentLoadOp,

const AttachmentStoreOp colorAttachmentStoreOp,

virtual std::unique_ptr<IFramebuffer> CreateFramebuffer(

const CColor& clearColor, ITexture* depthStencilAttachment,

const char* name, ITexture* colorAttachment,

const AttachmentLoadOp depthStencilAttachmentLoadOp,

ITexture* depthStencilAttachment, const CColor& clearColor) = 0;

const AttachmentStoreOp depthStencilAttachmentStoreOp) = 0;

phositUnsubmitted

Done

* @return A valid framebuffer if it was created successfully else nullptr.

+ struct Attachment

+ {

+ ITexture* data;

+ AttachmentLoadOp loadOp;

+ AttachmentStoreOp storeOp;

+ };

virtual std::unique_ptr<IFramebuffer> CreateFramebuffer(

- const char* name, ITexture* colorAttachment,

- const AttachmentLoadOp colorAttachmentLoadOp,

- const AttachmentStoreOp colorAttachmentStoreOp,

- const CColor& clearColor, ITexture* depthStencilAttachment,

- const AttachmentLoadOp depthStencilAttachmentLoadOp,

- const AttachmentStoreOp depthStencilAttachmentStoreOp) = 0;

+ const char* name, const Attachment colorAttachment,

+ const CColor& clearColor, const Attachment depthStencilAttachment) = 0;

virtual std::unique_ptr<IBuffer> CreateBuffer(

I would pack the args in to a struct.
Also you could make three function out of this: taking color attachment, taking depth stencil attachment and taking both. so "should not be nullptr at the same time" could be checked staticly but that's propably overkill.

phosit: I would pack the args in to a struct. Also you could make three function out of this: taking…

vladislavbelovAuthorUnsubmitted

Done

Yeah, I had the same thought. But the problem is that the client code becomes bigger. I'm still not sure.

vladislavbelov: Yeah, I had the same thought. But the problem is that the client code becomes bigger. I'm still…

phositUnsubmitted

Done

(suspecting by client you mean backend/implementation)

Using a struct: the client code does not become bigger.

Multiple functions: only the interface would have to implement the three functions and then call the clients "unsave" function.

phosit: (suspecting by client you mean backend/implementation) - Using a struct: the client code does…

vladislavbelovAuthorUnsubmitted

Done

By clients I mean users of the API ( who calls it): renderers and so on.

And I definitely agree that the struct makes the API better.

vladislavbelov: By clients I mean users of the API ( who calls it): renderers and so on. And I definitely…

virtual std::unique_ptr<IBuffer> CreateBuffer(

const char* name, const IBuffer::Type type, const uint32_t size, const bool dynamic) = 0;

virtual std::unique_ptr<IShaderProgram> CreateShaderProgram(

const CStr& name, const CShaderDefines& defines) = 0;

/**

* Acquires a backbuffer for rendering a frame.

* @return True if it was successfully acquired and we can render to it.

virtual bool AcquireNextBackbuffer() = 0;

/**

* Returns a framebuffer for the current backbuffer with the required

* attachment operations. It should not be called if the last

* AcquireNextBackbuffer call returned false.

* It's guaranteed that for the same acquired backbuffer this function returns

* a framebuffer with the same attachments and properties except load and

* store operations.

* @return The last successfully acquired framebuffer that wasn't

* presented.

virtual IFramebuffer* GetCurrentBackbuffer(

const AttachmentLoadOp colorAttachmentLoadOp,

const AttachmentStoreOp colorAttachmentStoreOp,

const AttachmentLoadOp depthStencilAttachmentLoadOp,

const AttachmentStoreOp depthStencilAttachmentStoreOp) = 0;

/**

* Presents the backbuffer to the swapchain queue to be flipped on a

* screen. Should be called only if the last AcquireNextBackbuffer call

* returned true.

virtual void Present() = 0;

virtual bool IsTextureFormatSupported(const Format format) const = 0;

virtual bool IsFramebufferFormatSupported(const Format format) const = 0;

virtual const Capabilities& GetCapabilities() const = 0;

};

} // namespace Backend

} // namespace Renderer

#endif // INCLUDED_RENDERER_BACKEND_IDEVICE